[Bug gdb/25560] Assertion `pid != 0' failed

[Bug gdb/25560] Assertion `pid != 0' failed

[delta512.dev at protonmail dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=25560

delta512.dev at protonmail dot com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |delta512.dev at protonmail dot com

--- Comment #1 from delta512.dev at protonmail dot com ---
# TL;DR

I'm getting this issue too! I'm on macOS High Sierra 10.13.6 and starting from
gdb-8.3.1 the debugger fails with the very same message each time the
"symbol-file" command is issued with a non-empty exec file.

Only the git upstream, gdb-10xxx, has a slightly different message (see
attachments), but it is still a matter of null PIDs.

An "easy" workaround is to issue the symbol command before the exec one. Fixing
the order inside the code for the combo "file" command works pretty neat.

BUT

as I said it's a workaround, I have no idea why this happens and no enough
skills to solve that.


# Extensive explanation

[ ARCH: x86_64 ]
[   OS: macOS High Sierra 10.13.6, Darwin 17.7.0 ]
[  GDB: gdb-8.3.1 or later ]

-> Discovery:
Trying to setup Eclipse CDT for embedded developments, I tried first the local
environment, just to stay on the safe side. So I downloaded gdb-9.2 release tar
and built it as per README. Simple, no errors so far. But, to my disappointment
I could not debug anything, not even the dumbest "hello world!" code.

I tried on Linux the very same setup and everything worked flawlessly. Checking
the gdb console Eclipse traces, the macOS one failed at the
"-file-exec-and-symbols" MI command.

-> Investigation:
After double-checking the code, turns out "-file-exec-and-symbols" directly
translates into the "file" console command. Same goes for the "exec-file" and
"symbol-file" individual commands.

Now, invoking gdb with the inferior as an argument does NOT throw ANY error.
Therefore, I played a bit with option flags and commands:

   > WORKS   $: gdb inferior

   > WORKS   $: gdb -se inferior

   ! FAILS   (gdb) file inferior

   ! FAILS   $:gdb -e inferior
             (gdb) symbol-file inferior

   ! FAILS   (gdb) exec-file inferior
             (gdb) symbol-file inferior

   > WORKS   (gdb) symbol-file inferior
             (gdb) exec-file inferior

   > WORKS   $: gdb -s inferior
             (gdb) exec-file inferior

It fails right away, even before you run the target (and get the Development
Tools Access prompt).

-> Culprit:
What follows is my understanding of where the issue lies. Clearly, there's
something wrong in the execution of 'exec_file_command()' BEFORE and the
'symbol_file_command()' AFTER, be it 'file_command()' or separate calls.
(gdb/exec.c:395:428, gdb/symfile.c:1611)

On the other hand, this issue does NOT happen when 'exec_file_attach()' and
'symbol_file_add_main()' are involved, as it is for command line invocation
(i.e. -se or no option, gdb/main.c:1074).

So, the issue lies in the additional stuff inside 'symbol_file_command()'
inside gdb/symfile.c:1611.

As documented in the terminal listings attached, 'symbol_file_add_main_1()' is
actually pretty well behaved. (gdb/symfile.c:1672)

The trouble comes right in the next 'solib_create_inferior_hook()' function
(gdb/symfile.c:1674). In particular, the good and bad cases branch inside
'gdbarch_data()' at 'if (gdbarch->data[data->index] == NULL)'.
(gdb/gdbarch.c:5251)

The good case turns out to be NULL and enters the 'if'. (gdb/gdbarch.c:5255)

The bad cases skips the 'if' and 'else if' and goes straight to the last 'else
return NULL;' at line 5277.

That's why the bad gdb ends up calling
'darwin_solib_get_all_image_info_addr_at_init()' in gdb/solib-darwin.c:454,
while the good one completely avoids that. In the listing you can see the last
sane step is 'load_addr =' at line 465. The "next" gdb command leads straight
to doomsday at gdb/thread.c:94, where 'find_thread_ptid()' calls the infamous
'find_thread_pid()' at gdb/inferior.c:283, last stop.

-> Versions affected:
I started with gdb-9.2 release tarball. I confirm this issue for gdb-8.3.1 and
for the binutils-gdb git upstream (kind of gdb-10).

Please note, the git version fails as well, but the error message is different
(while still consistent with the NULL pid). See the "test-versions-output.txt"
attached.

However, versions 7.12.1 (the one the Debian VM had) and 8.0.1 work flawlessly.

Now, as macOS has been painful for gdb-8.1 and this issue matches that version
gap, maybe the fix found at the time just pushed the problem a bit further.

(gdb-9.2 built on Debian worked perfectly)

-> Workaround:
Now, for what matters, I was able to get gdb-9.2 and Eclipse CDT work perfectly
by simply swapping 'exec_file_command()' and 'symbol_file_command()' inside
'file_command()'. (gdb/exec.c:428)

-> Message to the skilled ones:
I won't claim it is a solution, for I have no idea why all that happens, nor I
have the required skills to fix it. I tried to provide as much detail as
possible, hope it is sufficient.

Many thanks in advance to the developers that will tackle this!

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug gdb/25560] Assertion `pid != 0' failed

[delta512.dev at protonmail dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=25560

--- Comment #2 from delta512.dev at protonmail dot com ---
Created attachment 12741
  --> https://sourceware.org/bugzilla/attachment.cgi?id=12741&action=edit
Terminal listing, GDB versions.

This terminal listing shows no error up to gdb-8.0.1, the reported issue from
gdb-8.3.1 on and the different message from upstream GDB.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug gdb/25560] Assertion `pid != 0' failed

[delta512.dev at protonmail dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=25560

--- Comment #3 from delta512.dev at protonmail dot com ---
Created attachment 12742
  --> https://sourceware.org/bugzilla/attachment.cgi?id=12742&action=edit
Terminal listing, debug session.

This terminal listing shows a (lame) debug session, with backtraces and value
prints for ptid.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug gdb/25560] Assertion `pid != 0' failed

[delta512.dev at protonmail dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=25560

--- Comment #4 from delta512.dev at protonmail dot com ---
Last thing...

GNU gdb (GDB) 9.2
This GDB was configured as "x86_64-apple-darwin17.7.0".

(gdb) show configuration 
This GDB was configured as follows:
   configure --host=x86_64-apple-darwin17.7.0
--target=x86_64-apple-darwin17.7.0
             --with-auto-load-dir=:${prefix}/share/auto-load
             --with-auto-load-safe-path=:${prefix}/share/auto-load
             --with-expat
             --with-gdb-datadir=/usr/local/share/gdb (relocatable)
             --with-jit-reader-dir=/usr/local/lib/gdb (relocatable)
             --without-libunwind-ia64
             --without-lzma
             --without-babeltrace
                             --without-intel-pt
             --without-mpfr
             --without-xxhash
            
--with-python=/System/Library/Frameworks/Python.framework/Versions/2.7
             --without-guile
             --disable-source-highlight
             --with-separate-debug-dir=/usr/local/lib/debug (relocatable)

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug gdb/25560] Assertion `pid != 0' failed

[tromey at sourceware dot org]

https://sourceware.org/bugzilla/show_bug.cgi?id=25560

Tom Tromey <tromey at sourceware dot org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |tromey at sourceware dot org

--- Comment #5 from Tom Tromey <tromey at sourceware dot org> ---
A stack trace of the crashing gdb might be helpful.
Note that the Darwin port isn't very actively maintained.
This is unfortunate but we have had trouble finding someone
with the needed hardware and the desire to make it work :(

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug gdb/25560] Assertion `pid != 0' failed

[delta512.dev at protonmail dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=25560

--- Comment #6 from Fil <delta512.dev at protonmail dot com> ---
(In reply to Tom Tromey from comment #5)
> A stack trace of the crashing gdb might be helpful.

Sure, there it is:

#0  0x00000001001bcf50 in find_inferior_pid (pid=<optimized out>) at
../../gdb/inferior.c:283
#1  0x0000000100320aed in find_thread_ptid (ptid=...) at ../../gdb/thread.c:524
#2  inferior_thread () at ../../gdb/thread.c:94
#3  0x000000010028201e in get_thread_arch_regcache (gdbarch=<optimized out>,
ptid=...) at ../../gdb/regcache.c:341
#4  get_thread_regcache (ptid=...) at ../../gdb/regcache.c:358
#5  get_thread_regcache (thread=<optimized out>) at ../../gdb/regcache.c:366
#6  0x0000000102809190 in ?? ()
#7  0x0000000102809190 in ?? ()
#8  0x00007ffeefbff4c0 in ?? ()
#9  0x00000001002bf9a2 in gdb_bfd_ref_policy::decref (abfd=<optimized out>) at
../../gdb/gdb_bfd.h:64
#10 gdb::ref_ptr<bfd, gdb_bfd_ref_policy>::~ref_ptr (this=<optimized out>) at
../../gdb/gdbsupport/gdb_ref_ptr.h:91
#11 gdb::ref_ptr<bfd, gdb_bfd_ref_policy>::~ref_ptr (this=<optimized out>) at
../../gdb/gdbsupport/gdb_ref_ptr.h:89
#12 darwin_get_dyld_bfd () at ../../gdb/solib-darwin.c:446
#13 0x00000001002bed90 in darwin_solib_get_all_image_info_addr_at_init
(info=<optimized out>) at ../../gdb/solib-darwin.c:465
#14 darwin_solib_create_inferior_hook (from_tty=<optimized out>) at
../../gdb/solib-darwin.c:515
#15 0x00000001002dca3f in symbol_file_command (args=<optimized out>,
from_tty=1) at ../../gdb/symfile.c:1674
#16 0x000000010015451d in file_command (arg=0x103026450 "", from_tty=41980304)
at ../../gdb/exec.c:433
#17 0x00000001000963f2 in cmd_func (cmd=0x102809190, args=0x100b232c0 "",
from_tty=0) at ../../gdb/cli/cli-decode.c:1952
#18 0x000000010032876c in execute_command (p=<optimized out>, from_tty=1) at
../../gdb/top.c:612
#19 0x0000000102800f35 in ?? ()
#20 0x0000000100c044c0 in ?? ()
#21 0x00007ffeefbff630 in ?? ()
#22 0x00007fff561fd5bf in malloc () from /usr/lib/system/libsystem_malloc.dylib
#23 0x0000000100151bbb in command_handler (command=0x102809190 "
\214\200\002\001") at ../../gdb/event-top.c:587
#24 0x0000000100151eb0 in command_line_handler (rl=...) at
../../gdb/event-top.c:772
#25 0x0000000100151410 in gdb_rl_callback_handler (rl=0x102809190 "
\214\200\002\001") at ../../gdb/event-top.c:218
#26 0x000000010039a86a in rl_callback_read_char () at
../../../readline/readline/callback.c:281
#27 0x00000001001525fe in gdb_rl_callback_read_char_wrapper_noexcept () at
../../gdb/event-top.c:176
#28 0x00000001001510b4 in gdb_rl_callback_read_char_wrapper
(client_data=<optimized out>) at ../../gdb/event-top.c:193
#29 0x0000000100151a80 in stdin_event_handler (error=<optimized out>,
client_data=0x103026450) at ../../gdb/event-top.c:515
#30 0x0000000100150432 in gdb_wait_for_event (block=<optimized out>) at
../../gdb/event-loop.c:854
#31 0x0000000100150094 in gdb_do_one_event () at ../../gdb/event-loop.c:346
#32 0x0000000100150515 in start_event_loop () at ../../gdb/event-loop.c:370
#33 0x00000001001faa1f in captured_command_loop () at ../../gdb/main.c:359
#34 0x00000001001f7c85 in captured_main (data=<optimized out>) at
../../gdb/main.c:1203
#35 gdb_main (args=<optimized out>) at ../../gdb/main.c:1217
#36 0x0000000100450e60 in ?? ()
#37 0x0000000000000000 in ?? ()

Thanks for your reply, if you need more information please check the new debug
session attached.

> Note that the Darwin port isn't very actively maintained.
> This is unfortunate but we have had trouble finding someone
> with the needed hardware and the desire to make it work :(

Yeah, I guess Apple is of no help anymore too. Unfortunately I'm building GDB
to learn how to use it properly, so my skills are not enough for sure.

Yet, if you could guide me I'll share as much details as possible and hopefully
sort this out.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug gdb/25560] Assertion `pid != 0' failed

[delta512.dev at protonmail dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=25560

--- Comment #7 from Fil <delta512.dev at protonmail dot com> ---
Created attachment 12760
  --> https://sourceware.org/bugzilla/attachment.cgi?id=12760&action=edit
Terminal listing, stack trace

Full listing from the debug session related to the stack trace

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug gdb/25560] Assertion `pid != 0' failed

[delta512.dev at protonmail dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=25560

--- Comment #8 from Fil <delta512.dev at protonmail dot com> ---
One more thing. I tried to follow by hand the brew formula with no help, even
the bottled binary I downloaded shows the same issue.

Now, what puzzles me is that gdb works perfectly when the target is provided as
an argument. What actions does the command perform that the argument does not?

If the symbol_file_command is issued first, no error shows up either, perhaps
gdb does not expect any thread (pid) in this case.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug gdb/25560] Assertion `pid != 0' failed

[erickitten at gmail dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=25560

Che-Kang Wu <erickitten at gmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |erickitten at gmail dot com

--- Comment #9 from Che-Kang Wu <erickitten at gmail dot com> ---
I found the same assertion fail on Windows 10 (Mingw32) to ARM cross-gdb when
remote debugging.
Bug 24825 also shows a similar issue, not sure if this is the same.

1) Example program
#include <stdio.h>
int main (void)
{
   printf("Hello world!\n");
   return 1;
}

2) Compile
arm-linux-gnueabihf-gcc -g 1.c

3) Remote
./gdbserver :12000 ./a.out
Process ./hello created; pid = 1421
Listening on port 12000

4) gdb host
arm-linux-gnueabihf-gdb.exe
GNU gdb (GDB) 9.2
(gdb)  show configuration
This GDB was configured as follows:
   configure --host=i686-w64-mingw32 --target=arm-linux-gnueabihf
             --with-auto-load-dir=$debugdir:$datadir/auto-load
             --with-auto-load-safe-path=$debugdir:$datadir/auto-load
             --with-expat
             --with-gdb-datadir=/usr/local/share/gdb (relocatable)
             --with-jit-reader-dir=/usr/local/lib/gdb (relocatable)
             --without-libunwind-ia64
             --without-lzma
             --without-babeltrace
                             --without-intel-pt
             --without-mpfr
             --without-xxhash
             --without-python
             --without-guile
             --disable-source-highlight
             --with-separate-debug-dir=/usr/local/lib/debug (relocatable)

5) Set breakpoint
(gdb) target remote xxx.xxx.xxx.xxx:12000

(gdb) b main
(gdb) c
Breakpoint 1, main () at 1.c:6
6          printf("Hello world!\n");

6) This works normally
(gdb) c
Continuing.
[Inferior 1 (process 1463) exited with code 01]
(gdb) q

7) But this fails
(gdb) n
# Next step to end

Single stepping until exit from function __libc_start_main,
which has no line number information.
[Inferior 1 (process 1457) exited with code 01]
You can't do that without a process to debug.
(gdb) q
/home/eric/project/standalone-build/source/gdb-9.2/gdb-build/../gdb/inferior.c:283:
internal-error: inferior* find_inferior_pid(int): Assertion `pid != 0' failed.
A problem internal to GDB has been detected,
further debugging may prove unreliable.
Quit this debugging session? (y or n) y

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug gdb/25560] Assertion `pid != 0' failed

[ddresser at bmc dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=25560

David Dresser <ddresser at bmc dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |ddresser at bmc dot com

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug gdb/25560] Assertion `pid != 0' failed

[dahllunde at gmail dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=25560

Vegz78 <dahllunde at gmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |dahllunde at gmail dot com

--- Comment #10 from Vegz78 <dahllunde at gmail dot com> ---
> -> Workaround:
> Now, for what matters, I was able to get gdb-9.2 and Eclipse CDT work
> perfectly by simply swapping 'exec_file_command()' and
> 'symbol_file_command()' inside 'file_command()'. (gdb/exec.c:428)
Thank you very much, @Fil, for your proposed work-around, which is now included
the Homebrew tap domq/gdb/gdb for quick 'n easy installation on MacOS.!
https://github.com/domq/homebrew-gdb

Your work-around handles this bug and the file command error reported in bug
27365, and it's now possible again to debug with gdb both locally on the Mac
and remotely from Visual Studio on Windows.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug gdb/25560] Assertion `pid != 0' failed

[delta512.dev at protonmail dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=25560

--- Comment #11 from Fil <delta512.dev at protonmail dot com> ---
(In reply to Vegz78 from comment #10)
> Thank you very much, @Fil, for your proposed work-around, which is now
> included the Homebrew tap domq/gdb/gdb for quick 'n easy installation on
> MacOS.!
> https://github.com/domq/homebrew-gdb

Glad it helped! Actually, this is my first successful contribution.

> Your work-around handles this bug and the file command error reported in bug
> 27365, and it's now possible again to debug with gdb both locally on the Mac
> and remotely from Visual Studio on Windows.

Please, keep in mind I still don't have full understanding of GDB internals, it
just worked and seemed sufficiently elegant.

Happy debugging to all!

-- 
You are receiving this mail because:
You are on the CC list for the bug.