Odd gdb problem

Odd gdb problem

[Lars Ingebrigtsen]

I'm seeing this on the current trunk (not emacs-28) and on
Debian/bookworm (not on Debian/bullseye, the stable Debian release).  I
don't think I've ever seen something like this before:

larsi@xo:~/src/emacs/trunk$ gdb ./src/emacs 
GNU gdb (Debian 10.1-2) 10.1.90.20210103-git
Copyright (C) 2021 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.

[...]

Type "apropos word" to search for commands related to "word"...
Reading symbols from ./src/emacs...
(gdb) run -Q .
Starting program: /home/larsi/src/emacs/trunk/src/emacs -Q .
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
[New Thread 0x7ffff172b640 (LWP 823779)]
[New Thread 0x7ffff0eaf640 (LWP 823780)]
[New Thread 0x7fffebfff640 (LWP 823781)]
[New Thread 0x7fffeb7fe640 (LWP 823782)]
[Thread 0x7fffeb7fe640 (LWP 823782) exited]
[New Thread 0x7fffeb7fe640 (LWP 823783)]
[New Thread 0x7fffeaffd640 (LWP 823784)]
[Thread 0x7fffeb7fe640 (LWP 823783) exited]
[New Thread 0x7fffeb7fe640 (LWP 823785)]
[New Thread 0x7fffea7fc640 (LWP 823786)]
[Thread 0x7fffeaffd640 (LWP 823784) exited]
[Thread 0x7fffeb7fe640 (LWP 823785) exited]
[Thread 0x7fffea7fc640 (LWP 823786) exited]
[Detaching after vfork from child process 823787]
[Thread 0x7fffebfff640 (LWP 823781) exited]
[Thread 0x7ffff0eaf640 (LWP 823780) exited]
[Thread 0x7ffff172b640 (LWP 823779) exited]

Program terminated with signal SIGTRAP, Trace/breakpoint trap.
The program no longer exists.
(gdb) 

That is, if I start "emacs -Q ." (i.e., open a dired buffer), then it
exits with SIGTRAP, which is something I can't recall having seen before
ever.  (And Emacs works fine from without gdb.)

I tried googling briefly, but no.  Does anybody know what this might
mean?

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Re: Odd gdb problem

[Eli Zaretskii]

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Date: Mon, 06 Dec 2021 20:43:50 +0100
> 
> Program terminated with signal SIGTRAP, Trace/breakpoint trap.
> The program no longer exists.
> (gdb) 
> 
> That is, if I start "emacs -Q ." (i.e., open a dired buffer), then it
> exits with SIGTRAP, which is something I can't recall having seen before
> ever.  (And Emacs works fine from without gdb.)

Is this with or without native-comp?

Did you try rebuilding Emacs (i.e. delete temacs and bootstrap-emacs,
and say "make")?

Re: Odd gdb problem

[Lars Ingebrigtsen]

Eli Zaretskii <eliz@gnu.org> writes:

> Is this with or without native-comp?

Without any configure options.

> Did you try rebuilding Emacs (i.e. delete temacs and bootstrap-emacs,
> and say "make")?

Yup; did a "make extraclean" first.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Re: Odd gdb problem

[Eli Zaretskii]

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Date: Mon, 06 Dec 2021 20:57:22 +0100
> Cc: emacs-devel@gnu.org
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > Is this with or without native-comp?
> 
> Without any configure options.
> 
> > Did you try rebuilding Emacs (i.e. delete temacs and bootstrap-emacs,
> > and say "make")?
> 
> Yup; did a "make extraclean" first.

SIGTRAP is normally the signal generated when the program hits a
breakpoint, so this is strange: it looks like GDB received a spurious
SIGTRAP that it couldn't associate with one of its breakpoints.  What
does "info break" say inside GDB?

One other idea I have is to say

  (gdb) handle SIGTRAP stop print pass

and see what happens then.  Maybe you will be able to see where does
this SIGTRAP originate from.

Re: Odd gdb problem

[Lars Ingebrigtsen]

Eli Zaretskii <eliz@gnu.org> writes:

> SIGTRAP is normally the signal generated when the program hits a
> breakpoint, so this is strange: it looks like GDB received a spurious
> SIGTRAP that it couldn't associate with one of its breakpoints.  What
> does "info break" say inside GDB?

(gdb) info break
No breakpoints or watchpoints.

> One other idea I have is to say
>
>   (gdb) handle SIGTRAP stop print pass
>
> and see what happens then.  Maybe you will be able to see where does
> this SIGTRAP originate from.

(gdb) handle SIGTRAP stop print pass
SIGTRAP is used by the debugger.
Are you sure you want to change it? (y or n) y
Signal        Stop	Print	Pass to program	Description
SIGTRAP       Yes	Yes	Yes		Trace/breakpoint trap
(gdb) run 
Starting program: /home/larsi/src/emacs/mystery/src/emacs 

Program terminated with signal SIGTRAP, Trace/breakpoint trap.
The program no longer exists.

This is with a fresh checkout.  I'm starting to think there's a bug in
the version of gdb on Debian/bookworm that the current trunk is somehow
hitting.  Perhaps I should just try to bisect the current trunk -- this
started happening this past week.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Re: Odd gdb problem

[Lars Ingebrigtsen]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> Perhaps I should just try to bisect the current trunk -- this
> started happening this past week.

Done.  And the culprit found at least makes some kind of sense as
something that could break gdb.

Philipp, after this change, I can no longer debug Emacs with gdb on
Debian/bookworm.  (It works fine with older gdb versions.)

Do you have any idea what in particular in this change might make gdb
just exit with:

Program terminated with signal SIGTRAP, Trace/breakpoint trap.


a60053f8368e058229721f1bf1567c2b1676b239 is the first bad commit
commit a60053f8368e058229721f1bf1567c2b1676b239
Author: Philipp Stephani <phst@google.com>
Date:   Wed Dec 30 14:42:01 2020 +0100

    Use posix_spawn if possible.
    
    posix_spawn is less error-prone than vfork + execve, and can make
    better use of system-specific enhancements like 'clone' on Linux.  Use
    it if we don't need to configure a pseudoterminal.
    
    * configure.ac (HAVE_SPAWN_H, HAVE_POSIX_SPAWN)
    (HAVE_POSIX_SPAWN_FILE_ACTIONS_ADDCHDIR)
    (HAVE_POSIX_SPAWN_FILE_ACTIONS_ADDCHDIR_NP)
    (HAVE_POSIX_SPAWNATTR_SETFLAGS, HAVE_DECL_POSIX_SPAWN_SETSID): New
    configuration variables.
    * src/callproc.c (USABLE_POSIX_SPAWN): New configuration macro.
    (emacs_posix_spawn_init_actions)
    (emacs_posix_spawn_init_attributes, emacs_posix_spawn_init): New
    helper functions.
    (emacs_spawn): Use posix_spawn if possible.

 configure.ac   |  17 ++++++
 src/callproc.c | 189 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++-
 2 files changed, 205 insertions(+), 1 deletion(-)



-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Re: Odd gdb problem

[Lars Ingebrigtsen]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> Philipp, after this change, I can no longer debug Emacs with gdb on
> Debian/bookworm.  (It works fine with older gdb versions.)

I've confirmed that simply disabling it on the current trunk makes the
problem disappear, so it's definitely the spawn code:

diff --git a/src/callproc.c b/src/callproc.c
index c949fff4db..ec44e982f3 100644
--- a/src/callproc.c
+++ b/src/callproc.c
@@ -37,7 +37,7 @@ Copyright (C) 1985-1988, 1993-1995, 1999-2021 Free Software Foundation,
   && defined HAVE_DECL_POSIX_SPAWN_SETSID                   \
   && HAVE_DECL_POSIX_SPAWN_SETSID == 1
 # include <spawn.h>
-# define USABLE_POSIX_SPAWN 1
+# define USABLE_POSIX_SPAWN 0
 #else
 # define USABLE_POSIX_SPAWN 0
 #endif


-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Re: Odd gdb problem

[Andreas Schwab]

On Dez 08 2021, Lars Ingebrigtsen wrote:

> Philipp, after this change, I can no longer debug Emacs with gdb on
> Debian/bookworm.  (It works fine with older gdb versions.)

Does it work with vanilla gdb?  I have no problem with gdb 11.1, so this
looks like something broken by debian, and you need to file a bug with
them.

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510  2552 DF73 E780 A9DA AEC1
"And now for something completely different."

Re: Odd gdb problem

[Lars Ingebrigtsen]

Andreas Schwab <schwab@linux-m68k.org> writes:

> Does it work with vanilla gdb?  I have no problem with gdb 11.1, so this
> looks like something broken by debian, and you need to file a bug with
> them.

This is with:

GNU gdb (Debian 10.1-2) 10.1.90.20210103-git

On Debian/bullseye, I don't see the problem, and that has:

GNU gdb (Debian 10.1-1.7) 10.1.90.20210103-git

I could try installing vanilla gdb, I guess, and see how that fares...
I'll give it a shot.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Re: Odd gdb problem

[Lars Ingebrigtsen]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> I could try installing vanilla gdb, I guess, and see how that fares...
> I'll give it a shot.

Vanilla gdb 11.1 fails the same way with the current trunk on this
laptop.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Re: Odd gdb problem

[Andreas Schwab]

On Dez 08 2021, Lars Ingebrigtsen wrote:

> Vanilla gdb 11.1 fails the same way with the current trunk on this
> laptop.

It can also be a kernel bug.

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510  2552 DF73 E780 A9DA AEC1
"And now for something completely different."

Re: Odd gdb problem

[Lars Ingebrigtsen]

Andreas Schwab <schwab@linux-m68k.org> writes:

> It can also be a kernel bug.

Yes, haven't tried rebooting into the latest kernel in a week...

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Re: Odd gdb problem

[Lars Ingebrigtsen]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> Andreas Schwab <schwab@linux-m68k.org> writes:
>
>> It can also be a kernel bug.
>
> Yes, haven't tried rebooting into the latest kernel in a week...

I now rebooted into a new kernel, and the gdb problem has disappeared.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no