lldb 3.9 no longer opens Breakpad generated dumps

[Quuxplusone]

Bugzilla Link	PR31464
Status	NEW
Importance	P normal
Reported by	rdorr@microsoft.com
Reported on	2016-12-24 17:45:12 -0800
Last modified on	2017-01-08 10:47:21 -0800
Version	unspecified
Hardware	PC Linux
CC	labath@google.com, llvm-bugs@lists.llvm.org
Fixed by commit(s)
Attachments	core.zi_ (149292 bytes, application/x-zip-compressed)
Blocks
Blocked by
See also

Created attachment 17780
Zip file containing a core file generated from breakpad

•   Opens with all versions of gdb
•   Opens with lldb 3.7
•   Fails to open with lldb 3.9

#0  0x00007ffff4e40120 in lldb_private::ArchSpec::GetMachine() const () from
/home/rdorr/eugene/llvm-3.9-Release/lib/liblldb.so.3.9.1  - rdi is 0x8 and
can’t be dereferenced
#1  0x00007ffff53a71bf in
RegisterContextPOSIX_x86::RegisterContextPOSIX_x86(lldb_private::Thread&,
unsigned int, lldb_private::RegisterInfoInterface*) ()
   from /home/rdorr/eugene/llvm-3.9-Release/lib/liblldb.so.3.9.1
#2  0x00007ffff52695f4 in
RegisterContextCorePOSIX_x86_64::RegisterContextCorePOSIX_x86_64(lldb_private::Thread&,
lldb_private::RegisterInfoInterface*, lldb_private::DataExtractor const&,
lldb_private::DataExtractor const&) () from /home/rdorr/eugene/llvm-3.9-
Release/lib/liblldb.so.3.9.1
#3  0x00007ffff526775f in
ThreadElfCore::CreateRegisterContextForFrame(lldb_private::StackFrame*) () from
/home/rdorr/eugene/llvm-3.9-Release/lib/liblldb.so.3.9.1
#4  0x00007ffff52672c5 in ThreadElfCore::GetRegisterContext() [clone
.localalias.37] () from /home/rdorr/eugene/llvm-3.9-Release/lib/liblldb.so.3.9.1
#5  0x00007ffff5010dd9 in lldb_private::Thread::SetupForResume() () from
/home/rdorr/eugene/llvm-3.9-Release/lib/liblldb.so.3.9.1
#6  0x00007ffff501653c in lldb_private::ThreadList::WillResume() () from
/home/rdorr/eugene/llvm-3.9-Release/lib/liblldb.so.3.9.1
#7  0x00007ffff4fd0f4f in lldb_private::Process::PrivateResume() () from
/home/rdorr/eugene/llvm-3.9-Release/lib/liblldb.so.3.9.1
#8  0x00007ffff4fd174f in
lldb_private::Process::ProcessEventData::DoOnRemoval(lldb_private::Event*) ()
from /home/rdorr/eugene/llvm-3.9-Release/lib/liblldb.so.3.9.1
#9  0x00007ffff4e86209 in
lldb_private::Listener::FindNextEventInternal(lldb_private::Mutex::Locker&,
lldb_private::Broadcaster*, lldb_private::ConstString const*, unsigned int,
unsigned int, std::shared_ptr<lldb_private::Event>&, bool) () from
/home/rdorr/eugene/llvm-3.9-Release/lib/liblldb.so.3.9.1
#10 0x00007ffff4e86951 in
lldb_private::Listener::WaitForEventsInternal(lldb_private::TimeValue const*,
lldb_private::Broadcaster*, lldb_private::ConstString const*, unsigned int,
unsigned int, std::shared_ptr<lldb_private::Event>&) () from
/home/rdorr/eugene/llvm-3.9-Release/lib/liblldb.so.3.9.1
#11 0x00007ffff4e86a44 in
lldb_private::Listener::WaitForEvent(lldb_private::TimeValue const*,
std::shared_ptr<lldb_private::Event>&) ()
   from /home/rdorr/eugene/llvm-3.9-Release/lib/liblldb.so.3.9.1
#12 0x00007ffff4fd0d17 in lldb_private::Process::LoadCore() () from
/home/rdorr/eugene/llvm-3.9-Release/lib/liblldb.so.3.9.1
#13 0x00007ffff3f0ccdf in lldb::SBTarget::LoadCore(char const*) () from
/home/rdorr/eugene/llvm-3.9-Release/lib/liblldb.so.3.9.1
#14 0x0000000000418864 in LldbHandler::LoadCore (this=0x7fffffffca88,
target=0x7fffffffe7ad "/home/rdorr/Source/mspal/Hosts/Linux/output/bin/palrun",
    core=0x69f6f0 "/home/rdorr/Temp/test.core", libPath=0x7fffffffe061 "") at debugger/LldbHandler.cpp:366
#15 0x00000000004687cd in LiveUserDebugServices::LoadCore (this=0x7fffffffca48,
target=0x7fffffffe7ad "/home/rdorr/Source/mspal/Hosts/Linux/output/bin/palrun",
    core=0x69f6f0 "/home/rdorr/Temp/test.core", libPath=0x7fffffffe061 "") at main/dbgsvc.cpp:143
#16 0x000000000046ce40 in main (argc=4, argv=0x7fffffffe518) at
main/main.cpp:313

•   Using readelf, I can see the PR_STATUS for the thread in question and has
register and other information.
•   Opening in gdb I can symbolize the stacks and do other operations.

[Quuxplusone]

Attached core.zi_ (149292 bytes, application/x-zip-compressed): Zip file containing a core file generated from breakpad

[Quuxplusone]

LLDB is failing to detect the core file as linux, therefore it does not create a register context and crashes. The linux-detection code has always been very messy and has undergone several changes in the past, so I guess one of them broke this.

BTW. lldb ToT should now be able to open minidump files natively, without converting them to core files. Have you tried using that?

[Quuxplusone]

Thanks for your reply.

Do you know who is looking at the LLDB problem/fix?

Sorry, when you say ToT what are you referring to exactly?

[Quuxplusone]

I don't believe anyone is looking at this problem at the moment.

By ToT I mean "svn trunk", the main development branch.

[Quuxplusone]

Changed the ES_OSAPI ident to ELFOSABI_LINUX using a hex editor and this dump now loads in lldb 3.9