public inbox for gdb-prs@sourceware.org help / color / mirror / Atom feed
From: "delta512.dev at protonmail dot com" <sourceware-bugzilla@sourceware.org> To: gdb-prs@sourceware.org Subject: [Bug gdb/25560] Assertion `pid != 0' failed Date: Sun, 02 Aug 2020 15:43:05 +0000 [thread overview] Message-ID: <bug-25560-4717-TVPZSHJKr9@http.sourceware.org/bugzilla/> (raw) In-Reply-To: <bug-25560-4717@http.sourceware.org/bugzilla/> 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.
next parent reply other threads:[~2020-08-02 15:43 UTC|newest] Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top [not found] <bug-25560-4717@http.sourceware.org/bugzilla/> 2020-08-02 15:43 ` delta512.dev at protonmail dot com [this message] 2020-08-02 15:46 ` delta512.dev at protonmail dot com 2020-08-02 15:48 ` delta512.dev at protonmail dot com 2020-08-02 15:51 ` delta512.dev at protonmail dot com 2020-08-09 20:33 ` tromey at sourceware dot org 2020-08-10 21:05 ` delta512.dev at protonmail dot com 2020-08-10 21:08 ` delta512.dev at protonmail dot com 2020-08-10 21:14 ` delta512.dev at protonmail dot com 2020-10-20 2:51 ` erickitten at gmail dot com 2020-12-13 13:15 ` ddresser at bmc dot com 2021-06-25 19:00 ` dahllunde at gmail dot com 2021-06-25 20:56 ` delta512.dev at protonmail dot com
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=bug-25560-4717-TVPZSHJKr9@http.sourceware.org/bugzilla/ \ --to=sourceware-bugzilla@sourceware.org \ --cc=gdb-prs@sourceware.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).