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
    Classification: Unclassified

Error and log messages:

elf-core::CreateRegisterContextForFrame:: Architecture(27) or OS(0) not
virtual lldb::RegisterContextSP
Assertion `false && "Architecture or OS not supported"' failed.

Problen seen on lldb trunk version 4.0.0
( 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


      llvm::StringRef path(cstr);
      if (path.startswith("/lib/x86_64-linux-gnu") ||
          path.startswith("/lib/i386-linux-gnu")) {

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
    0x00000000019bc000  0x00000000019d5000  0x00000000000013bc
    0x00007fbe4a139000  0x00007fbe4a339000  0x00000000000001ba
    0x00007fbe4a339000  0x00007fbe4a33d000  0x00000000000001ba
    0x00007fbe4a33d000  0x00007fbe4a33f000  0x00000000000001be

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

This solution was already hinted at by Ted Woodward here:

Offending core dump(s) available on request.

You are receiving this mail because:
You are the assignee for the bug.
lldb-dev mailing list

Reply via email to