GNU bug report logs - #75459
31.0.50; scratch-igc: Breakpoint 1, terminate_due_to_signal (sig=sig@entry=6, backtrace_limit=backtrace_limit@entry=2147483647) at ./src/emacs.c:432

Previous Next

Full log

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

From: Pip Cet <pipcet <at> protonmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: gerd.moellmann <at> gmail.com, telegraph <at> gmx.net, 75459 <at> debbugs.gnu.org
Subject: Re: bug#75459: 31.0.50;
 scratch-igc: Breakpoint 1, terminate_due_to_signal (sig=sig <at> entry=6,
 backtrace_limit=backtrace_limit <at> entry=2147483647) at ./src/emacs.c:432
Date: Fri, 10 Jan 2025 15:30:12 +0000

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

>> Date: Fri, 10 Jan 2025 13:46:40 +0000
>> From: Pip Cet <pipcet <at> protonmail.com>
>> Cc: Eli Zaretskii <eliz <at> gnu.org>, telegraph <at> gmx.net, 75459 <at> debbugs.gnu.org
>>
>> If calling backtrace in GDB means we can't continue afterwards, that
>> would be very bad.  I think it's already bad that we automatically
>> append the Lisp backtrace to "bt" output.  IMHO, "bt" should limit
>> itself to accessing process memory via PTRACE, not call into application
>> code.  Making it destroy the Emacs session even when we can get a
>> backtrace would be worse.
>
> Usually, automatically calling xbacktrace is very useful.  In cases

Point taken.  IIRC, I destroyed a GDB session by calling "bt" on the
wrong thread (which had no Lisp backtrace, but the C backtrace was all
that I was interested in).  In hindsight, I should have just fixed that
case in .gdbinit.  I wrote a patch to do so, but now I'm no longer sure
it's a good idea:

diff --git a/src/eval.c b/src/eval.c
index b214870984c..8af819bc9dd 100644
--- a/src/eval.c
+++ b/src/eval.c
@@ -169,6 +169,18 @@ backtrace_p (union specbinding *pdl)
 backtrace_thread_p (struct thread_state *tstate, union specbinding *pdl)
 { return pdl >= tstate->m_specpdl; }
 
+bool
+backtrace_current_thread_p_body (void)
+{
+  /* GDB may call us on the wrong system thread.  It's better not to
+     display a Lisp backtrace automatically in that case.  */
+  if (!sys_thread_equal (sys_thread_self (), current_thread->thread_id))
+    return false;
+
+  return true;
+}
+GDB_FUNCPTR (backtrace_current_thread_p, bool, (void));
+
 union specbinding *
 backtrace_top (void)
 {
diff --git a/src/.gdbinit b/src/.gdbinit
index 40c1a6081fe..cc25fce93b5 100644
--- a/src/.gdbinit
+++ b/src/.gdbinit
@@ -1278,11 +1278,13 @@ end
 
 # Show Lisp backtrace after normal backtrace.
 define hookpost-backtrace
-  set $bt = backtrace_top ()
-  if backtrace_p ($bt)
-    echo \n
-    echo Lisp Backtrace:\n
-    xbacktrace
+  if backtrace_current_thread_p ()
+    set $bt = backtrace_top ()
+    if backtrace_p ($bt)
+      echo \n
+      echo Lisp Backtrace:\n
+      xbacktrace
+    end
   end
 end

The problem is this would make debugging slightly less convenient on
macOS (where MPS exceptions are handled on the "wrong" thread) and
possibly Windows (I don't know what sys_thread_self () does for the
additional threads we use on that system).  If there's a risk of losing
valuable backtraces for the redisplay code, for example, we should keep
the automatic backtrace and I'll turn it off locally when creating
additional threads.

> where it is not, one can disable it, like this:
>
>   (gdb)  define hookpost-backtrace
>   Redefine command "hookpost-backtrace"? (y or n) y
>   Type commands for definition of "hookpost-backtrace".
>   End with a line saying just "end".
>   >end
>   (gdb)
>
> (It is also possible to start GDB from a directory other than the
> Emacs src directory, but then one loses the other conveniencies of our
> .gdbinit.)

I think the .gdbinit code is extremely useful, and it'd be great if we
could somehow cause it to be sourced for gdb run in other directories,
too.  (The main emacs/ directory is pure laziness, but I often cd to
lisp/ when debugging ELC compilation issues, because that's where the
command lines "make" produces will work).

(This is off-topic, but we could make all Makefiles use paths relative
to the emacs root directory, and use "$(MAKE) -f $@/Makefile" rather
than "$(MAKE) -C $@".  That would involve rewriting the msdos/ sed
scripts, or dropping the MSDOS port entirely.  The same is true for any
major change to the build system, but I think only non-recursive GNU
make is an option worth considering.  The "new" make replacements, IMHO,
seem inferior to GNU make in every way but performance.  Configure is
unbearably slow on emulated systems, but that's fixable without moving
to some non-GNU nightmare.  The actual compilation is okay because we
can parallelize it.)

Pip

Previous Next

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