[Bug symtab/32658] New: GDB sometimes fails parsing debug information

["pixel@nobis-crew.org" <sourceware-bugzilla@sourceware.org>]

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.