[lldb-dev] LLDB 3.9 on Linux crashes when loading core dump

[Eugene Birukov via lldb-dev]

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>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/lldb-dev/attachments/20170119/ad29da99/attachment-0001.html>