Michael Albinus <michael.albinus@gmx.de> writes:

> 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.

If you are prompted for password of course you have to enter your password.

> I did. Now Helm offers me something, which I always confirm with RET,

Helm offers you completion on your system files and offer you to
navigate with arrow keys or C-j C-l, if you press RET on a directory it
opens this directory in a dired buffer, on a file in a buffer to edit file.

> 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).

Ah ok, I noticed I have always in ~/.emacs.d/tramp an UNKNOW entry for
uid and gid, is it normal?

>>> 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?

I can't reproduce the crash using helm -P path/to/emacs though there is
not much difference with my helm-find-files config, the difference comes
I guess from the usage of normal emacs (or possibly only -q) and emacs
-Q which affect tramp in some ways.

What I would like to understand is why the crash appears AFTER
tramp-cleanup-all-connections and not before on first shot.


-- 
Thierry