bug#55832: 28.1; Emacs crashes when using tramp from helm in emacs-29

[Michael Albinus <michael.albinus@gmx.de>]

Thierry Volpiatto <thievol@posteo.net> writes:

> Hello Michael,

Hi Thierry,

>> First, I've tried to reproduce it from emacs -Q. I've upgraded all
>> installed ELPA packages, and then I have called
>>
>> emacs -Q \
>>   -l ~/.emacs.d/elpa/helm-core-20220503.622/helm-core-autoloads.el \
>>   -l ~/.emacs.d/elpa/helm-20220504.827/helm-autoloads.el \
>>   -l ~/.emacs.d/elpa/helm-tramp-20190616.125/helm-tramp-autoloads.el \
>
> What is helm-tramp? this is not part of helm.

I've installed this as ELPA package a while ago, don't remember the
details. So I've taken this out, calling now Emacs master branch like

emacs -Q \
  -l ~/.emacs.d/elpa/helm-core-20220503.622/helm-core-autoloads.el \
  -l ~/.emacs.d/elpa/helm-20220504.827/helm-autoloads.el \
  -l ~/.emacs.d/elpa/async-20220318.1342/async-autoloads.el -l seq

> You have better time cloning emacs-async and run make && sudo make
> install and same with helm, then emacs -q, (require 'helm) (require
> 'helm-config) and C-x c C-x C-f

Hmm, this would poison my laptop with an undesired config. Shouldn't the
call above be sufficient?

>> Using /sudo:: as file name doesn't raise any error.
>
> Did you follow the recipe I sent?
> First shot doesn't crash but second after M-x
> tramp-cleanup-all-connections does.

Ahh, this was another message I didn't notice.

>> However, this is from the master branch;
>
> The bug is from master branch not emacs-28, I sent the bug report from
> my main emacs which is emacs-28 because 29 crashed.

OK, rerunning your recipe with the invocation as above:

> 1) Ensure you have no entries for sudo in .authinfo.gpg file.

Not needed, because I call "emacs -Q".

> 2) M-x helm-find-files RET // sudo::

Done.

> 3) You are prompted for password

Yep.

> 4) At this first shot it should work as expected.

Not clear to me whether I shall enter the password. I did. Now Helm
offers me something, which I always confirm with RET, until I see the
dired buffer of "/sudo:root@gandalf:/root". "gandalf" is the name of my laptop.

> 5) C-g to quit, and M-x tramp-cleanup-all-connections.

Done.

> 6) Restart helm-find-files and enter /sudo:: emacs should freeze and crash.

I've switched to the *scratch* buffer, and did this. No problem.

-----

Now a second attempt. Steps 1-3 as above.

> 4) At this first shot it should work as expected.

I didn't enter the password.

> 5) C-g to quit, and M-x tramp-cleanup-all-connections.

Done. I have applied C-g twice in order to go out of the minibuffer.

> 6) Restart helm-find-files and enter /sudo:: emacs should freeze and crash.

No, Emacs asks me for the /sudo:: password, and continues as expected.

>> tramp-get-remote-uid *is* a valid argument, and
>> tramp-file-name-for-operation shouldn't raise an error. Once we have
>> fixed the problem of Emacs crash, it shall be investigated wy this error
>> has been raised.
>
> tramp-get-remote-uid is calling tramp-file-name-handler with
> tramp-get-remote-uid as arg so I guess the infinite recursion starts
> here isn't it?

No. tramp-get-remote-uid invokes tramp-file-name-handler in order to get
a method specific implementation (finally, tramp-sh-handle-get-remote-uid
shall be called).

>> It is not clear to me why tramp-file-name-for-operation goes into
>> recursion with the error handling, invoking again and again
>> tramp-signal-hook-function (that is the function bound to
>> signal-hook-function).
>
> What is calling tramp-get-remote-uid in tramp-file-name-for-operation?

tramp-get-remote-uid should *not* be called inside
tramp-file-name-for-operation.  The symbol is passed as argument, and
used for investigation of the other args.

>> Similar protections have been applied already elsewhere in Tramp. Does
>> this solve the problem?
>
> No still crashing.

Sad. Since I cannot reproduce the problem locally, what happens if you
invoke "emacs -Q" similar to how I've done?

Best regards, Michael.