public inbox for gdb-prs@sourceware.org help / color / mirror / Atom feed
From: "pixel@nobis-crew.org" <sourceware-bugzilla@sourceware.org> To: gdb-prs@sourceware.org Subject: [Bug symtab/32658] New: GDB sometimes fails parsing debug information Date: Fri, 07 Feb 2025 16:19:00 +0000 [thread overview] Message-ID: <bug-32658-4717@http.sourceware.org/bugzilla/> (raw) https://sourceware.org/bugzilla/show_bug.cgi?id=32658 Bug ID: 32658 Summary: GDB sometimes fails parsing debug information Product: gdb Version: HEAD Status: UNCONFIRMED Severity: normal Priority: P2 Component: symtab Assignee: unassigned at sourceware dot org Reporter: pixel@nobis-crew.org Target Milestone: --- Created attachment 15930 --> https://sourceware.org/bugzilla/attachment.cgi?id=15930&action=edit Test elf file which fails parsing its debug information I've yet to fully investigate what's going on, but I figured I'd start by reporting what I have so far in case someone already has some ideas. Since commit 3d20b8d99a54382e6e1a6c433e71e0775c6856c6 which introduced the new DWARF indexer, some of the ELF files I'm producing using normal gcc aren't able to display their debug information anymore. I've attached one of these ELF files as an example. Before the new DWARF indexer, with this ELF file, I can do this properly: (gdb) info line *0x800334b0 Line 44 of "src/application.cpp" starts at address 0x800334b0 <_ZN5psyqo11Application3runEv> and ends at 0x800334bc <_ZN5psyqo11Application3runEv+12>. After this commit however, I get the following: (gdb) info line *0x800334b0 No line number information available for address 0x800334b0 <_ZN5psyqo11Application3runEv> and this is true for most of the addresses of the binary. My current working theory is some pieces of code sometimes produce debug information which gdb can't parse properly, and that its parser just stops mid-way. To better demonstrate what I am talking about instead of just using the info line command, this binary in particular has an assert mid-processing, and with a gdb built after this commit, I get the following stacktrace: (gdb) bt #0 0x8003e7f0 in pcsx_debugbreak () #1 0x8003eb90 in check_subintegrity () #2 0x8003ef9c in check_integrity () #3 0x8003f73c in psyqo_free () #4 0x80010a68 in free () #5 0x8002f49c in l_alloc () #6 0x8001a270 in luaM_realloc_ () #7 0x8001d714 in luaH_resize () #8 0x8001d8e0 in rehash () #9 0x8001db90 in luaH_newkey () #10 0x8001e140 in luaH_set () #11 0x80026490 in luaX_newstring () #12 0x80028f20 in llex () #13 0x800290dc in luaX_next () #14 0x8002ea8c in funcstat () #15 0x8002ef7c in statement () #16 0x8002bc40 in statlist () #17 0x8002f154 in mainfunc () #18 0x8002f324 in luaY_parser () #19 0x80014ee4 in f_parser () #20 0x800135ac in luaD_rawrunprotected () #21 0x80014c08 in luaD_pcall () #22 0x80015094 in luaD_protectedparser () #23 0x80011f5c in lua_load () #24 0x8002f458 in luaL_loadbufferx () #25 0x800109a8 in (anonymous namespace)::LuaScene::frame() () #26 0x80033608 in psyqo::Application::run() () #27 0x80010a40 in main () (gdb) However, if I run a gdb prior to that commit, I get the following: (gdb) bt #0 pcsx_debugbreak () at /home/pixel/sources/lua-derp/third_party/nugget/common/hardware/pcsxhw.h:32 #1 0x8003eb90 in check_subintegrity (first=0x80046240, top=0x80046940, size_start=8, hypothetical_size=1800) at src/alloc.c:131 #2 0x8003ef9c in check_integrity () at src/alloc.c:200 #3 0x8003f73c in psyqo_free (ptr_=0x80046948) at src/alloc.c:408 #4 0x80010a68 in free (ptr=0x80046948) at lua.cpp:97 #5 0x8002f49c in l_alloc (ud=0x0, ptr=0x80046948, osize=20, nsize=0) at lauxlib.c:754 #6 0x8001a270 in luaM_realloc_ (L=0x80045e90, block=0x80046948, osize=20, nsize=0) at lmem.c:84 #7 0x8001d714 in luaH_resize (L=0x80045e90, t=0x800468d8, nasize=0, nhsize=2) at ltable.c:331 #8 0x8001d8e0 in rehash (L=0x80045e90, t=0x800468d8, ek=0x80046020) at ltable.c:356 #9 0x8001db90 in luaH_newkey (L=0x80045e90, t=0x800468d8, key=0x80046020) at ltable.c:413 #10 0x8001e140 in luaH_set (L=0x80045e90, t=0x800468d8, key=0x80046020) at ltable.c:512 #11 0x80026490 in luaX_newstring (ls=0x801ffb50, str=0x800468b0 "native_callback_loopUso\215\030\004+▌\004'b- i\004\200(", l=20) at llex.c:127 #12 0x80028f20 in llex (ls=0x801ffb50, seminfo=0x801ffb60) at llex.c:492 #13 0x800290dc in luaX_next (ls=0x801ffb50) at llex.c:519 #14 0x8002ea8c in funcstat (ls=0x801ffb50, line=3) at lparser.c:1470 #15 0x8002ef7c in statement (ls=0x801ffb50) at lparser.c:1558 #16 0x8002bc40 in statlist (ls=0x801ffb50) at lparser.c:609 #17 0x8002f154 in mainfunc (ls=0x801ffb50, fs=0x801ffb8c) at lparser.c:1610 #18 0x8002f324 in luaY_parser (L=0x80045e90, z=0x801ffd10, buff=0x801ffca8, dyd=0x801ffcb4, name=0x80041810 "?", firstchar=102) at lparser.c:1630 #19 0x80014ee4 in f_parser (L=0x80045e90, ud=0x801ffca4) at ldo.c:661 #20 0x800135ac in luaD_rawrunprotected (L=0x80045e90, f=0x80014d48 <f_parser>, ud=0x801ffca4) at ldo.c:141 #21 0x80014c08 in luaD_pcall (L=0x80045e90, func=0x80014d48 <f_parser>, u=0x801ffca4, old_top=8, ef=0) at ldo.c:613 #22 0x80015094 in luaD_protectedparser (L=0x80045e90, z=0x801ffd10, name=0x80041810 "?", mode=0x0) at ldo.c:682 #23 0x80011f5c in lua_load (L=0x80045e90, reader=0x8002f380 <getS>, data=0x801ffd48, chunkname=0x80041810 "?", mode=0x0) at lapi.c:979 #24 0x8002f458 in luaL_loadbufferx (L=0x80045e90, buff=0x8004442c <this_code_causes_blackscreen> "function native_callback_init(game, w, h)\nend\nfunction native_callback_loop(dt)\nend\nfunction native_callback_draw()\n native_draw_rect(0, 10, 10, 20, 20)\nend\n", size=160, name=0x80041810 "?", mode=0x0) at lauxlib.c:519 #25 0x800109a8 in (anonymous namespace)::LuaScene::frame (this=0x80045258 <(anonymous namespace)::luaScene>) at lua.cpp:85 #26 0x80033608 in psyqo::Application::run (this=0x80044800 <(anonymous namespace)::lua>) at src/application.cpp:58 #27 0x80010a40 in main () at lua.cpp:93 Note this happens on a per-binary basis. Some binaries will display their debug information properly in gdb, some others will not, and I have yet to narrow down what makes it so. All binaries have been built using the same exact compilation flags, so I don't think it's very relevant, and that instead it's about the contents of said code causing the issue, but let me know if you want to be able to reproduce this yourself, and I'll happily share some test repository. It'll contain a lot of code however. I'm now going to try debugging a bit inside of gdb to see if my theory is correct and what kind of DWARF/DIE record makes gdb choke. -- You are receiving this mail because: You are on the CC list for the bug.
next reply other threads:[~2025-02-07 16:19 UTC|newest] Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top 2025-02-07 16:19 pixel@nobis-crew.org [this message] 2025-02-07 16:19 ` [Bug symtab/32658] " sam at gentoo dot org 2025-02-07 17:30 ` tromey at sourceware dot org 2025-02-08 11:14 ` ssbssa at sourceware dot org 2025-02-21 19:16 ` tromey at sourceware dot org 2025-02-22 5:09 ` pixel@nobis-crew.org 2025-02-24 12:28 ` qqxnjvamvxwx at dyxyl dot com 2025-03-06 18:37 ` pixel@nobis-crew.org 2025-03-07 3:47 ` sam at gentoo dot org
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-32658-4717@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).