llvm-objdump crashed

[yiming564]

log:

kernel/xCore:   file format elf64-x86-64
PLEASE submit a bug report to https://github.com/llvm/llvm-project/issues/ and include the crash backtrace.
Stack dump:
0.      Program arguments: llvm-objdump -D kernel/xCore

kernel/xCore is uploaded here.

I am using Ubuntu 24.04 + WSL2. This fault can be stably reproduced.

[llvmbot]

@llvm/issue-subscribers-tools-llvm-objdump

Author: yiming564 (yiming564)

log:

kernel/xCore:   file format elf64-x86-64
PLEASE submit a bug report to https://github.com/llvm/llvm-project/issues/ and include the crash backtrace.
Stack dump:
0.      Program arguments: llvm-objdump -D kernel/xCore

kernel/xCore is uploaded here.

I am using Ubuntu 24.04 + WSL2. This fault can be stably reproduced.

[EugeneZelenko]

Which version do you use?

[yiming564]

@EugeneZelenko Sorry, I should have mentioned it at the beginning {{{(>_<)}}}

Ubuntu LLVM version 18.1.3
  Optimized build.


  Registered Targets:
    aarch64     - AArch64 (little endian)
    aarch64_32  - AArch64 (little endian ILP32)
    aarch64_be  - AArch64 (big endian)
    amdgcn      - AMD GCN GPUs
    arm         - ARM
    arm64       - ARM64 (little endian)
    arm64_32    - ARM64 (little endian ILP32)
    armeb       - ARM (big endian)
    avr         - Atmel AVR Microcontroller
    bpf         - BPF (host endian)
    bpfeb       - BPF (big endian)
    bpfel       - BPF (little endian)
    hexagon     - Hexagon
    lanai       - Lanai
    loongarch32 - 32-bit LoongArch
    loongarch64 - 64-bit LoongArch
    m68k        - Motorola 68000 family
    mips        - MIPS (32-bit big endian)
    mips64      - MIPS (64-bit big endian)
    mips64el    - MIPS (64-bit little endian)
    mipsel      - MIPS (32-bit little endian)
    msp430      - MSP430 [experimental]
    nvptx       - NVIDIA PTX 32-bit
    nvptx64     - NVIDIA PTX 64-bit
    ppc32       - PowerPC 32
    ppc32le     - PowerPC 32 LE
    ppc64       - PowerPC 64
    ppc64le     - PowerPC 64 LE
    r600        - AMD GPUs HD2XXX-HD6XXX
    riscv32     - 32-bit RISC-V
    riscv64     - 64-bit RISC-V
    sparc       - Sparc
    sparcel     - Sparc LE
    sparcv9     - Sparc V9
    systemz     - SystemZ
    thumb       - Thumb
    thumbeb     - Thumb (big endian)
    ve          - VE
    wasm32      - WebAssembly 32-bit
    wasm64      - WebAssembly 64-bit
    x86         - 32-bit X86: Pentium-Pro and above
    x86-64      - 64-bit X86: EM64T and AMD64
    xcore       - XCore
    xtensa      - Xtensa 32

I installed llvm-18 via apt-get and didn't modified anything.

By the way, objdump can correctly analyze my program.

I didn't see anything was wrong, but the fact is llvm-objdump did crashed without any detail output, which made me very confused. Can you reproduce it?

[cabbaken]

It looks like something wrong with the Nhdr addressi in advanceNhdr().
Maybe the key point of the problem:

llvm/Object/ELFTypes.h:720: Nhdr = reinterpret_cast<const Elf_Nhdr_Impl<ELFT> *>(NhdrPos + NoteSize);

Is there any known similar issue?

[EugeneZelenko]

Could you please try 19, 20 or main branch?

[yiming564]

@EugeneZelenko I tried 19.1.1 and it still crashed:

xCore:  file format elf64-x86-64
PLEASE submit a bug report to https://github.com/llvm/llvm-project/issues/ and include the crash backtrace.
Stack dump:
0.      Program arguments: llvm-objdump-19 -D xCore
Stack dump without symbol names (ensure you have llvm-symbolizer in your PATH or set the environment var `LLVM_SYMBOLIZER_PATH` to point to it):
0  libLLVM.so.19.1 0x00007a8765ebd0af llvm::sys::PrintStackTrace(llvm::raw_ostream&, int) + 63
1  libLLVM.so.19.1 0x00007a8765ebadb9 llvm::sys::RunSignalHandlers() + 89
2  libLLVM.so.19.1 0x00007a8765ebd800
3  libc.so.6       0x00007a8764845330
4  libLLVM.so.19.1 0x00007a87677a3ca1
5  libLLVM.so.19.1 0x00007a87677a2d6b llvm::object::getBuildID(llvm::object::ObjectFile const*) + 1915
6  llvm-objdump-19 0x00005cb36a1c7c76
7  llvm-objdump-19 0x00005cb36a1c6251
8  llvm-objdump-19 0x00005cb36a1bac46
9  llvm-objdump-19 0x00005cb36a2596b3
10 libc.so.6       0x00007a876482a1ca
11 libc.so.6       0x00007a876482a28b __libc_start_main + 139
12 llvm-objdump-19 0x00005cb36a1b2605
Segmentation fault (core dumped)

(Good, at least it gives more information)

And I'm sorry I don't have more time to build a latest llvm from scratch.

[cabbaken]

@EugeneZelenko I tried 19.1.1 and it still crashed:

xCore:  file format elf64-x86-64
PLEASE submit a bug report to https://github.com/llvm/llvm-project/issues/ and include the crash backtrace.
Stack dump:
0.      Program arguments: llvm-objdump-19 -D xCore
Stack dump without symbol names (ensure you have llvm-symbolizer in your PATH or set the environment var `LLVM_SYMBOLIZER_PATH` to point to it):
0  libLLVM.so.19.1 0x00007a8765ebd0af llvm::sys::PrintStackTrace(llvm::raw_ostream&, int) + 63
1  libLLVM.so.19.1 0x00007a8765ebadb9 llvm::sys::RunSignalHandlers() + 89
2  libLLVM.so.19.1 0x00007a8765ebd800
3  libc.so.6       0x00007a8764845330
4  libLLVM.so.19.1 0x00007a87677a3ca1
5  libLLVM.so.19.1 0x00007a87677a2d6b llvm::object::getBuildID(llvm::object::ObjectFile const*) + 1915
6  llvm-objdump-19 0x00005cb36a1c7c76
7  llvm-objdump-19 0x00005cb36a1c6251
8  llvm-objdump-19 0x00005cb36a1bac46
9  llvm-objdump-19 0x00005cb36a2596b3
10 libc.so.6       0x00007a876482a1ca
11 libc.so.6       0x00007a876482a28b __libc_start_main + 139
12 llvm-objdump-19 0x00005cb36a1b2605
Segmentation fault (core dumped)

(Good, at least it gives more information)

And I'm sorry I don't have more time to build a latest llvm from scratch.

I tried in main upstream, it crashed and the backtraces is:

 #0 0x000055c71f64a758 llvm::sys::PrintStackTrace(llvm::raw_ostream&, int) /home/cabbaken/llvm/llvm/lib/Support/Unix/Signals.inc:799:13
 #1 0x000055c71f648680 llvm::sys::RunSignalHandlers() /home/cabbaken/llvm/llvm/lib/Support/Signals.cpp:106:18
 #2 0x000055c71f64aef8 SignalHandler(int) /home/cabbaken/llvm/llvm/lib/Support/Unix/Signals.inc:415:1
 #3 0x00007efdd3069cd0 (/usr/lib/libc.so.6+0x3dcd0)
 #4 0x000055c71f54aaec unsigned int llvm::support::endian::read<unsigned int, 1ul>(void const*, llvm::endianness) /home/cabbaken/llvm/llvm/include/llvm/Support/Endian.h:61:3
 #5 0x000055c71f54aaec unsigned int llvm::support::endian::read<unsigned int, (llvm::endianness)1, 1ul>(void const*) /home/cabbaken/llvm/llvm/include/llvm/Support/Endian.h:70:10
 #6 0x000055c71f54aaec llvm::support::detail::packed_endian_specific_integral<unsigned int, (llvm::endianness)1, 1ul, 1ul>::operator unsigned int() const /home/cabbaken/llvm/llvm/include/llvm/Support/Endian.h:227:12
 #7 0x000055c71f54aaec llvm::object::Elf_Nhdr_Impl<llvm::object::ELFType<(llvm::endianness)1, true>>::getSize(unsigned long) const /home/cabbaken/llvm/llvm/include/llvm/Object/ELFTypes.h:633:44
 #8 0x000055c71f54aaec llvm::object::Elf_Note_Iterator_Impl<llvm::object::ELFType<(llvm::endianness)1, true>>::advanceNhdr(unsigned char const*, unsigned long) /home/cabbaken/llvm/llvm/include/llvm/Object/ELFTypes.h:721:17
 #9 0x000055c71f54a2a9 llvm::object::Elf_Note_Iterator_Impl<llvm::object::ELFType<(llvm::endianness)1, true>>::operator==(llvm::object::Elf_Note_Iterator_Impl<llvm::object::ELFType<(llvm::endianness)1, true>>) const /home/cabbaken/llvm/llvm/include/llvm/Object/ELFTypes.h:747:10
#10 0x000055c71f54a2a9 llvm::object::Elf_Note_Iterator_Impl<llvm::object::ELFType<(llvm::endianness)1, true>>::operator!=(llvm::object::Elf_Note_Iterator_Impl<llvm::object::ELFType<(llvm::endianness)1, true>>) const /home/cabbaken/llvm/llvm/include/llvm/Object/ELFTypes.h:754:20
#11 0x000055c71f54a2a9 llvm::ArrayRef<unsigned char> (anonymous namespace)::getBuildID<llvm::object::ELFType<(llvm::endianness)1, true>>(llvm::object::ELFFile<llvm::object::ELFType<(llvm::endianness)1, true>> const&) /home/cabbaken/llvm/llvm/lib/Object/BuildID.cpp:36:17
#12 0x000055c71f54a2a9 llvm::object::getBuildID(llvm::object::ObjectFile const*) /home/cabbaken/llvm/llvm/lib/Object/BuildID.cpp:62:12
#13 0x000055c71f0f7cc5 llvm::ArrayRef<unsigned char>::empty() const /home/cabbaken/llvm/llvm/include/llvm/ADT/ArrayRef.h:163:40
#14 0x000055c71f0f7cc5 fetchBinaryByBuildID(llvm::object::ObjectFile const&) /home/cabbaken/llvm/llvm/tools/llvm-objdump/llvm-objdump.cpp:1645:15
#15 0x000055c71f0f64b7 disassembleObject(llvm::object::ObjectFile*, bool) /home/cabbaken/llvm/llvm/tools/llvm-objdump/llvm-objdump.cpp:2628:45
#16 0x000055c71f0f64b7 dumpObject(llvm::object::ObjectFile*, llvm::object::Archive const*, llvm::object::Archive::Child const*) /home/cabbaken/llvm/llvm/tools/llvm-objdump/llvm-objdump.cpp:3320:5
#17 0x000055c71f0ed05b dumpInput(llvm::StringRef) (/usr/local/bin/llvm-objdump+0x19d005b)
#18 0x000055c71f0ed05b void (*std::for_each<__gnu_cxx::__normal_iterator<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char>>*, std::vector<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char>>, std::allocator<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char>>>>>, void (*)(llvm::StringRef)>(__gnu_cxx::__normal_iterator<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char>>*, std::vector<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char>>, std::allocator<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char>>>>>, __gnu_cxx::__normal_iterator<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char>>*, std::vector<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char>>, std::allocator<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char>>>>>, void (*)(llvm::StringRef)))(llvm::StringRef) /usr/lib64/gcc/x86_64-pc-linux-gnu/14.2.1/../../../../include/c++/14.2.1/bits/stl_algo.h:3786:2
#19 0x000055c71f0ed05b void (*llvm::for_each<std::vector<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char>>, std::allocator<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char>>>>&, void (*)(llvm::StringRef)>(std::vector<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char>>, std::allocator<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char>>>>&, void (*)(llvm::StringRef)))(llvm::StringRef) /home/cabbaken/llvm/llvm/include/llvm/ADT/STLExtras.h:1733:10
#20 0x000055c71f0ed05b llvm_objdump_main(int, char**, llvm::ToolContext const&) /home/cabbaken/llvm/llvm/tools/llvm-objdump/llvm-objdump.cpp:3748:3
#21 0x000055c71f17df67 main /home/cabbaken/llvm/llvm/build/tools/llvm-objdump/llvm-objdump-driver.cpp:17:10
#22 0x00007efdd3053488 (/usr/lib/libc.so.6+0x27488)
#23 0x00007efdd305354c __libc_start_main (/usr/lib/libc.so.6+0x2754c)
#24 0x000055c71f0e4b95 _start (/usr/local/bin/llvm-objdump+0x19c7b95)

[jh7370]

It looks like something wrong with the Nhdr addressi in advanceNhdr(). Maybe the key point of the problem:

llvm/Object/ELFTypes.h:720: Nhdr = reinterpret_cast<const Elf_Nhdr_Impl *>(NhdrPos + NoteSize);

Is there any known similar issue?

I'm not aware of one specifically.

If the address is invalid, then it's reasonable for llvm-objcopy to emit a warning/error, but it shouldn't crash.

What happens when dumping note sections using another tool, e.g. llvm-readelf --notes?

[cabbaken]

It looks like something wrong with the Nhdr addressi in advanceNhdr(). Maybe the key point of the problem:
llvm/Object/ELFTypes.h:720: Nhdr = reinterpret_cast<const Elf_Nhdr_Impl *>(NhdrPos + NoteSize);
Is there any known similar issue?

I'm not aware of one specifically.

If the address is invalid, then it's reasonable for llvm-objcopy to emit a warning/error, but it shouldn't crash.

What happens when dumping note sections using another tool, e.g. llvm-readelf --notes?

It(llvm-readelf) runs properly with the same result as readelf.
I noticed that the value of Phdr.filesz is so big(0x10000000000000000, may exceed the limit of uint32_t, I will check the reason after the work on my hand). There may be some error when read program headers so it cant process malformed elf correctly.

[cabbaken]

The reason llvm-readelf worked properly but llvm-objdump crashed may be that llvm-readelf uses Section Header to read Note info, and llvm-objdump uses Program Header, the Program Header is corrupted in this file.
Do you have any ideas or advice on fixing this issue?
@jh7370

[jh7370]

The reason llvm-readelf worked properly but llvm-objdump crashed may be that llvm-readelf uses Section Header to read Note info, and llvm-objdump uses Program Header, the Program Header is corrupted in this file.

What happens if you strip the section headers from the file, using e.g. llvm-strip --strip-sections and then try to use llvm-readelf to dump the notes? Does it fall back to the program headers and if so, what does it do in this case?

the Program Header is corrupted in this file.

How is the program header corrupted exactly? Could you dump the program headers using llvm-readelf and post the output here, please?

If the program header is corrupt, that's the fault of the producer and not llvm-objdump's fault. As noted, we should still not crash and llvm-objdump should be improved to complain in a non-crashing manner about the problem.