Hi,
I have a Linux core dump that causes LLDB 3.9 on Linux crash. I would greatly
appreciate any advise how to deal with the problem or what else I should look
at.
The core dump was produced by GDB and GDB itself opens it without problems.
So, during loading the core we call
DynamicLoaderPOSIXDYLD::LoadAllCurrentModules() which enumerates all the
modules and does some processing. In the course of actions, it calls the
ObjectFileELF::GetSectionHeaderInfo() for each module. This guy tries to load
section headers and read string table. Well, it gets some garbage in the
section header struct and tries to allocate 1.5TB memory which causes operator
new throw.
So, why we get garbage?
The module in question is libc++abi.so.1:
521 ModuleSP module_sp = LoadModuleAtAddress(I->file_spec,
I->link_addr, I->base_addr, true);
(gdb) p I->file_spec
$95 = {
m_directory = {
m_string = 0x829a58 "... redacted ..."
},
m_filename = {
m_string = 0x7cc9e8 "libc++abi.so.1"
},
m_is_resolved = false,
m_syntax = lldb_private::FileSpec::ePathSyntaxPosix
}
The module header lives at address 0x7f699a270000 and looks OK. The section
headers are supposed to be at offset 2495600 == 0x261470
$96 = (const elf::ELFHeader &) @0x953a78: {
e_ident = "\177ELF\002\001\001\000\000\000\000\000\000\000\000",
e_entry = 33392,
e_phoff = 64,
e_shoff = 2495600,
e_flags = 0,
e_version = 1,
e_type = 3,
e_machine = 62,
e_ehsize = 64,
e_phentsize = 56,
e_phnum = 7,
e_shentsize = 64,
e_shnum = 38,
e_shstrndx = 35
}
LLDB tries to read the section headers from that address 0x7f699a270000 +
0x261470 == 0x7F699A4D1470 without a second thought, but this number is a lie.
The /proc/<pid>/maps file shows it as belonging to something else:
7f699a270000-7f699a2ba000 r-xp 00000000 fd:02 537796791
.../libc++abi.so.1
7f699a2ba000-7f699a4b9000 ---p 0004a000 fd:02 537796791
.../libc++abi.so.1
7f699a4b9000-7f699a4bb000 r--p 00049000 fd:02 537796791
.../libc++abi.so.1
7f699a4bb000-7f699a4bc000 rw-p 0004b000 fd:02 537796791
.../libc++abi.so.1
7f699a4bc000-7f699a520000 r-xp 00000000 fd:00 202587414
/usr/lib64/libssl.so.1.0.1e
7f699a520000-7f699a71f000 ---p 00064000 fd:00 202587414
/usr/lib64/libssl.so.1.0.1e
7f699a71f000-7f699a723000 r--p 00063000 fd:00 202587414
/usr/lib64/libssl.so.1.0.1e
7f699a723000-7f699a72a000 rw-p 00067000 fd:00 202587414
/usr/lib64/libssl.so.1.0.1e
I.e. LLDB should verify the module boundaries and fall back to some other plan
if the memory is not there.
Now the question is - where would be the right place to do the fix?
Thanks,
Eugene
Sent from Outlook<http://aka.ms/weboutlook>
_______________________________________________
lldb-dev mailing list
[email protected]
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
