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

["delta512.dev at protonmail dot com" <sourceware-bugzilla@sourceware.org>]

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.