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

Previous Next

Full log

View this message in rfc822 format

From: Thierry Volpiatto <thievol <at> posteo.net>
To: Michael Albinus <michael.albinus <at> gmx.de>
Cc: Eli Zaretskii <eliz <at> gnu.org>, larsi <at> gnus.org, 55832 <at> debbugs.gnu.org
Subject: bug#55832: 28.1; Emacs crashes when using tramp from helm in emacs-29
Date: Sat, 11 Jun 2022 06:14:02 +0000

[Message part 1 (text/plain, inline)]

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

> Thierry Volpiatto <thievol <at> 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

[signature.asc (application/pgp-signature, inline)]

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.