GNU bug report logs - #32502
27.0.50; Tramp; C-g during asynchronous remote find-file kills Emacs

Previous Next

Full log

View this message in rfc822 format

From: Michael Albinus <michael.albinus <at> gmx.de>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: gazally <at> runbox.com, 32502 <at> debbugs.gnu.org
Subject: bug#32502: 27.0.50; Tramp; C-g during asynchronous remote find-file kills Emacs
Date: Sat, 25 Aug 2018 12:53:02 +0200

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

Eli Zaretskii <eliz <at> gnu.org> writes:

Hi Eli,

>> > #3 0x000000000057115b in Fsignal (error_symbol=<optimized out>,
>> > data=<optimized out>) at eval.c:1582
>> > #4 0x00000000005d5555 in post_acquire_global_lock
>> > (self=self <at> entry=0xc19320 <main_thread>) at thread.c:93
>> 
>> And in frame #4, what is current_thread->error_symbol?
>
> Michael, unless I'm missing something, it sounds like Tramp signals
> the main thread in this scenario.  (current_thread->error_symbol is
> only set by thread-signal.)  Is that really necessary?  If so, can you
> describe why you needed to signal the main thread, while it was
> waiting for input?

Tramp propagates all signals to the main thread, otherwise they are not
visible. But this might be problematic for the quit signal.

I could not reproduce the problem myself, but this was said already by
Gemini that it isn't easy. The following patch does not propagate the
quit (and debug) signals do the main thread. Does it help?

However, if we apply this I don't know how to quit (let's say) 250
threads. One quit signal is good for one thread only. I believe we need
also a mechanism to quit many threads at once.

Best regards, Michael.

[Message part 2 (text/plain, attachment)]

Previous Next

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