From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id 9039E3858D35; Sun, 2 Aug 2020 15:43:05 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 9039E3858D35 From: "delta512.dev at protonmail dot com" To: gdb-prs@sourceware.org Subject: [Bug gdb/25560] Assertion `pid != 0' failed Date: Sun, 02 Aug 2020 15:43:05 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gdb X-Bugzilla-Component: gdb X-Bugzilla-Version: 9.1 X-Bugzilla-Keywords: X-Bugzilla-Severity: critical X-Bugzilla-Who: delta512.dev at protonmail dot com X-Bugzilla-Status: UNCONFIRMED X-Bugzilla-Resolution: X-Bugzilla-Priority: P2 X-Bugzilla-Assigned-To: unassigned at sourceware dot org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: cc Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: http://sourceware.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: gdb-prs@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gdb-prs mailing list List-Unsubscribe: , List-Archive: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Aug 2020 15:43:05 -0000 https://sourceware.org/bugzilla/show_bug.cgi?id=3D25560 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 f= rom 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. Fi= xing 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 lo= cal 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 disappoint= ment I could not debug anything, not even the dumbest "hello world!" code. I tried on Linux the very same setup and everything worked flawlessly. Chec= king 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" a= nd "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] =3D=3D 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 'e= lse 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 l= ast sane step is 'load_addr =3D' at line 465. The "next" gdb command leads stra= ight to doomsday at gdb/thread.c:94, where 'find_thread_ptid()' calls the infamo= us '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 differ= ent (while still consistent with the NULL pid). See the "test-versions-output.t= xt" attached. However, versions 7.12.1 (the one the Debian VM had) and 8.0.1 work flawles= sly. Now, as macOS has been painful for gdb-8.1 and this issue matches that vers= ion 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 perfe= ctly 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, no= r 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! --=20 You are receiving this mail because: You are on the CC list for the bug.=