New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
lldb fails to stack unwind gold linker exes that assert #19143
Comments
Whoops - wasn't done entering info. Here is lldb debugging this core: tfiala@tfiala2:~/lldb/hello/linux-x86_64$ ~/lldb/git/llgs/build/bin/lldb -c core -- ~/lldb/git/llgs/build/bin/lldb-gdbserver
Here is gdb debugging this core: tfiala@tfiala2:~/lldb/hello/linux-x86_64$ gdb ~/lldb/git/llgs/build/bin/lldb-gdbserver core <http://go/gdb-home FAQ: http://go/gdb-faq Email: gdb-team IRC: gdb> warning: Can't read pathname for load map: Input/output error. |
Here's what I've got so far. ~/lldb/git/llgs/build-gold/bin/lldb -c core -- ~/lldb/git/llgs/build-gold/bin/lldb-gdbserver Results: (lldb) image lookup -a $pc nothing?(lldb) step 0 no threads - ??(lldb) thread list
it seems to know about a thread. The one that did an assert.(lldb) image list hey - it knows about the exe. That's a start. |
Info from gdb on the same core, this time including '(gdb) info shared'. Perhaps we're failing to get all the module info loaded. tfiala@tfiala2:~/lldb/hello/linux-x86_64$ gdb ~/lldb/git/llgs/build-gold/bin/lldb-gdbserver core <http://go/gdb-home FAQ: http://go/gdb-faq Email: gdb-team IRC: gdb> warning: Can't read pathname for load map: Input/output error. |
Full logging on the startup: tfiala@tfiala2:~/lldb/hello/linux-x86_64$ ~/lldb/git/llgs/build-gold/bin/lldb main-thread DataBufferMemoryMap::Clear() m_mmap_addr = 0x7f3b6af66000, m_mmap_size = 2018024 main-thread Thread::ShouldStop(0x7f3b640009b0) for tid = 0x0000 0x0000, pc = 0x00007f87bb32d425 main-thread th1/fr0 using architectural default unwind method main-thread th1/fr0 cfa_regval = 0x00007f87c1081ab0 (cfa_regval = 0x00007f87c1081aa0, cfa_offset = 16) main-thread vvvvvvvv Thread::ShouldStop End (returning 1) vvvvvvvv
(lldb) image list ====== I see that the general module loading seems to be finding many modules that don't later show up in the image list. I'm not sure if this is relevant, but the output for the module list building seems to be implying that it is deleting the modules shortly after constructing them. I'm going to drill in on that next. |
ModuleList's call to module->GetObjectFile() appears to be failing. Looking at that next. This is causing the module to be deleted shortly after being created, for each .so. |
Live debugging of lldb-gdbserver with gold linker-linked lldb-gdbserver and lldb seems to show modules just fine. From top of tree earlier today: gold linker, live lldb-gdbserver (via './lldb ./lldb-gdbserver', then 'run'): ./lldb ./lldb-gdbserver
==================== Running lldb-gdbserver, producing a core, and then debugging the core produces very different results (and matches what I was initially reporting): tfiala@tfiala2:
===== Looking at how core files are processed now. |
Showing module loading during the core files with configure/(g)make and standard linker: tfiala@tfiala2:~/lldb/git/llgs/build-autoconf/Debug+Asserts/bin$ ./lldb
Notice the two passes at module resolution. Now with gold linker and cmake/ninja build; tfiala@tfiala2:~/lldb/git/llgs/build-gold/bin$ ./lldb
Notice we only take one pass through the modules. |
DynamicLoaderPOSIXDYLD::LoadAllCurrentModules() is failing in the m_rendezvous.Resolve() in the case of a core file from a gold-linked exe. This case succeeds in the case of a core file from a standard-linked exe. These two logs are helpful from lldb: (lldb) log enable lldb dyld |
ResolveRendezvousAddress(Process*) within DYLDRendezvous.cpp:40 appears to be failing to read the memory location for the image info. That makes me think that perhaps the section loading from the core is failing in some subtle way that doesn't map all the memory correctly. This causes DYLDRendezvous::Resolve() to fail. Looking at that next. |
Fixed with r201214. Net result: elf core file segment collapsing had a bug in it. The collapse code would collapse VMA-contiguous regions when the core-file-backed contents were contiguous; however, it failed to account for the case where there was zero padding at the end of the earlier/left side of the segment merge. This was exactly the scenario that the gold linker was producing in the core for my case. The DYLD rendezvous (the communication point between the linker and the debugger in elf land) failed to look up due to this bug, in which case all shared library info was lost. That meant lldb knew about no images (image list showed empty), and back traces that went through shared library code could not be stack unwound through because their memory segments were not present. |
Extended Description
I'm hitting an assertion in lldb-gdbserver. On Ubuntu 12.04 x86_64, using the gold linker 'sudo apt-get install binutils-gold', with a cmake/ninja build, I am not able to get a valid backtrace out of lldb for lldb-gdbserver when it generates
The text was updated successfully, but these errors were encountered: