[lldb-dev] [Bug 30485] New: lldb assertion "Architecture or OS not supported" when loading Ubuntu core dump

[via lldb-dev]

https://llvm.org/bugs/show_bug.cgi?id=30485

            Bug ID: 30485
           Summary: lldb assertion "Architecture or OS not supported" when
                    loading Ubuntu core dump
           Product: lldb
           Version: 3.9
          Hardware: PC
                OS: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: All Bugs
          Assignee: lldb-dev at lists.llvm.org
          Reporter: richard_chamberlain at uk.ibm.com
                CC: llvm-bugs at lists.llvm.org
    Classification: Unclassified

Error and log messages:

elf-core::CreateRegisterContextForFrame:: Architecture(27) or OS(0) not
supported
lldb:
/home/rchamberlain/lldb/llvm/tools/lldb/source/Plugins/Process/elf-core/ThreadElfCore.cpp:146:
virtual lldb::RegisterContextSP
 ThreadElfCore::CreateRegisterContextForFrame(lldb_private::StackFrame*):
Assertion `false && "Architecture or OS not supported"' failed.

Problen seen on lldb trunk version 4.0.0
(http://llvm.org/svn/llvm-project/lldb/trunk revision 281963 clang revision
281963 llvm revision 281963). Also fails on lldb 3.9.0.

The core dump was produced by an Ubuntu 14.04 instance (OS version: Linux
3.19.0-33-generic #38~14.04.1-Ubuntu SMP Fri Nov 6 18:17:28 UTC 2015) running
in IBM Bluemix/Cloud Foundry. Core dumps from Ubuntu running 'on the metal'
work fine. The difference seems to be that the library paths in the ELF notes
section that lldb uses to identify the core dump as Linux have an additional
prefix in the failing case. So the check for a path that starts with
/lib/x86_64-linux-gnu does not work for these core dumps. Relevant lldb code is
here:

Plugins/ObjectFile/ELF/ObjectFileELF.cpp
ObjectFileELF::RefineModuleDetailsFromNote()

      llvm::StringRef path(cstr);
      if (path.startswith("/lib/x86_64-linux-gnu") ||
          path.startswith("/lib/i386-linux-gnu")) {
        arch_spec.GetTriple().setOS(llvm::Triple::OSType::Linux);

Notes section in core dump:

~/test$ readelf -n core-node-6-100-1470315046
Displaying notes found at file offset 0x000023b0 with length 0x00003d14:
  Owner                 Data size    Description
  CORE                 0x00000150    NT_PRSTATUS (prstatus structure)
  CORE                 0x00000088    NT_PRPSINFO (prpsinfo structure)
  CORE                 0x00000080    NT_SIGINFO (siginfo_t data)
  CORE                 0x00000130    NT_AUXV (auxiliary vector)
  CORE                 0x000017db    NT_FILE (mapped files)
    Page size: 4096
                 Start                 End         Page Offset
    0x0000000000400000  0x00000000017bc000  0x0000000000000000
        /warden/depot/19p5hmkqpps/tmp/rootfs/home/vcap/app/vendor/node/bin/node
    0x00000000019bc000  0x00000000019d5000  0x00000000000013bc
    ....
        /packages/rootfs_cflinuxfs2/..../lib/x86_64-linux-gnu/libc-2.19.so
    0x00007fbe4a139000  0x00007fbe4a339000  0x00000000000001ba
       
/packages/rootfs_cflinuxfs2/..../rootfs/lib/x86_64-linux-gnu/libc-2.19.so
    0x00007fbe4a339000  0x00007fbe4a33d000  0x00000000000001ba
       
/packages/rootfs_cflinuxfs2/..../rootfs/lib/x86_64-linux-gnu/libc-2.19.so
    0x00007fbe4a33d000  0x00007fbe4a33f000  0x00000000000001be
    ....

Suggested fix would be to widen the test slightly, e.g.
path.find("/lib/x86_64-linux-gnu") rather than
path.startswith("/lib/x86_64-linux-gnu")

This solution was already hinted at by Ted Woodward here:
http://lists.llvm.org/pipermail/lldb-dev/2016-August/010974.html

Offending core dump(s) available on request.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/lldb-dev/attachments/20160922/ca117983/attachment.html>