GNU bug report logs - #76427
31.0.50; feature/igc: terminate_due_to_signal (sig=sig@entry=6, backtrace_limit=backtrace_limit@entry=2147483647) at ./src/emacs.c:425

Previous Next

Full log

Message #29 received at 76427 <at> debbugs.gnu.org (full text, mbox):

From: Pip Cet <pipcet <at> protonmail.com>
To: Gregor Zattler <telegraph <at> gmx.net>
Cc: 76427 <at> debbugs.gnu.org
Subject: Re: bug#76427: 31.0.50;
 feature/igc: terminate_due_to_signal (sig=sig <at> entry=6,
 backtrace_limit=backtrace_limit <at> entry=2147483647) at ./src/emacs.c:425
Date: Wed, 26 Feb 2025 17:30:59 +0000

"Gregor Zattler" <telegraph <at> gmx.net> writes:

> Hi Pip,

Hello!

>> indicating that read_char restored a jump buffer from stack space that
>> was no longer reserved.

The code looks fine (sorry it took a while to read): while it's very
unusual that Emacs copies jmp_buf structures (rather than pointers to
them), that doesn't appear to be the problem here.  (I don't think it's
safe either, because longjmping to a half-copied jmpbuf is likely to
cause trouble, but I have no evidence that has happened here).

I have not been able to verify that this comment in keyboard.c is
accurate:

      c = c_volatile;
      /* Handle quits while reading the keyboard.  */
      /* We must have saved the outer value of getcjmp here,
	 so restore it now.  */
      restore_getcjmp (save_jump);

One potential problem is that there are two jmpbufs called save_jump,
one in read_char and one in read_event_from_main_queue, and we may be
restoring from the one in read_char after saving to the one in
read_event_from_main_queue.  But again, no evidence that this is what is
in fact happening, and I don't know which recent compiler change may
have resulted in so many potentially read_char-setjmp related crashes
lately.

I suspect that if we clean up keyboard.c to store, on the heap, a
pointer to an on-stack jmpbuf, rather than storing an entire jmpbuf on
the heap and memcpy-ing to and fro, we would likely either catch the bug
(there's some evidence it may be a use-after-free, longjmping to a
jmpbuf whose stack pointer is no longer valid because the function has
exited) or work around any underlying GCC bug (somewhat worryingly, I
ran into an internal compiler error when playing with this code, but
it's not reproducible and may not be related, or maybe it's specific to
the gentoo gcc).

In any case, while I don't really know a good way to do it, could we
find a way to include the .comment ELF section of the Emacs executable
in M-x report-emacs-bug?  We desperately need that information to be
able to reproduce compiler-specific bugs.

(Maybe it's good enough to capture the gcc version at configure time,
though of course it's possible for gcc to be updated between configure
time and build time).

> HTH, and thanks for your attention, Gregor

Thanks, it does help and disprove that theory!

Pip

Previous Next

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