Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

ld.lld.exe segfaulting #418

Closed
nidefawl opened this issue Mar 25, 2024 · 4 comments
Closed

ld.lld.exe segfaulting #418

nidefawl opened this issue Mar 25, 2024 · 4 comments

Comments

@nidefawl
Copy link

nidefawl commented Mar 25, 2024 •
edited
Loading

Here is a working reproducer for a segfault in lld.
I tested 17.0.6 and 18.1.2. Both are crashing. I don't know if this has been reported upstream before.

The crash goes away when I remove either line from the CMakeLists.txt

add_link_options(-Wl,--gc-sections)
add_compile_options(-ffunction-sections -fdata-sections)

It also does not crash when building in release mode without -g

git clone --recursive https://github.com/nidefawl/vst3-lld-crash.git
C:\dev\vst3-lld-crash>cmake -G"Ninja Multi-Config" -S . -Bbuild

-- The C compiler identification is Clang 18.1.2
-- The CXX compiler identification is Clang 18.1.2
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Check for working C compiler: C:/dev/bin/llvm-mingw-20240320-ucrt-x86_64/bin/clang.exe - skipped
-- Detecting C compile features
-- Detecting C compile features - done
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Check for working CXX compiler: C:/dev/bin/llvm-mingw-20240320-ucrt-x86_64/bin/clang++.exe - skipped
-- Detecting CXX compile features
-- Detecting CXX compile features - done
-- [SMTG] SMTG_AAX_SDK_PATH is not set. If you need it, please download the AAX SDK!
-- Could NOT find LIBJACK (missing: LIBJACK_LIBRARIES LIBJACK_INCLUDE_DIR) 
-- Performing Test SMTG_USE_STDATOMIC_H
-- Performing Test SMTG_USE_STDATOMIC_H - Success
-- Configuring done (1.6s)
-- Generating done (0.2s)
-- Build files have been written to: C:/dev/vst3-lld-crash/build

C:\dev\vst3-lld-crash>cmake --build build --config Debug --target test_vst3sdk


...
5 warnings generated.
[38/38 100% :: 4.379] Linking CXX executable Debug\test_vst3sdk.exe
FAILED: Debug/test_vst3sdk.exe 
C:\WINDOWS\system32\cmd.exe /C "cd . && C:\dev\bin\llvm-mingw-20240320-ucrt-x86_64\bin\clang++.exe -g -Wl,--gc-sections CMakeFiles/test_vst3sdk.dir/Debug/main.cpp.obj -o Debug\test_vst3sdk.exe -Wl,--out-implib,Debug\libtest_vst3sdk.dll.a -Wl,--major-image-version,0,--minor-image-version,0  lib/Debug/libsdk_hosting.a  lib/Debug/libsdk_common.a  lib/Debug/libbase.a  lib/Debug/libpluginterfaces.a  -lkernel32 -luser32 -lgdi32 -lwinspool -lshell32 -lole32 -loleaut32 -luuid -lcomdlg32 -ladvapi32 && cd ."
PLEASE submit a bug report to https://github.com/llvm/llvm-project/issues/ and include the crash backtrace.
Exception Code: 0xC0000005
#0 0x00007ff7df950145 (C:\dev\bin\llvm-mingw-20240320-ucrt-x86_64\bin\ld.lld.exe+0x2d0145)
#1 0x00007ff95a6d3efd std::__1::deque<std::__1::function<void ()>, std::__1::allocator<std::__1::function<void ()>>>::__add_back_capacity() (C:\dev\bin\llvm-mingw-20240320-ucrt-x86_64\bin\libLLVM-18.dll+0xd3efd)
#2 0x00007ff95a6d3e0c std::__1::deque<std::__1::function<void ()>, std::__1::allocator<std::__1::function<void ()>>>::__add_back_capacity() (C:\dev\bin\llvm-mingw-20240320-ucrt-x86_64\bin\libLLVM-18.dll+0xd3e0c)
#3 0x00007ff95a6d27f5 std::__1::vector<std::__1::thread, std::__1::allocator<std::__1::thread>>::__append(unsigned long long) (C:\dev\bin\llvm-mingw-20240320-ucrt-x86_64\bin\libLLVM-18.dll+0xd27f5)
#4 0x00007ff95a6d29b0 std::__1::vector<std::__1::thread, std::__1::allocator<std::__1::thread>>::__append(unsigned long long) (C:\dev\bi
ninja: build stopped: subcommand failed.
n\llvm-mingw-20240320-ucrt-x86_64\bin\libLLVM-18.dll+0xd29b0)
#5 0x00007ff99df81bb2 (C:\WINDOWS\System32\ucrtbase.dll+0x21bb2)
#6 0x00007ff99e377344 (C:\WINDOWS\System32\KERNEL32.DLL+0x17344)
#7 0x00007ff9a00826b1 (C:\WINDOWS\SYSTEM32\ntdll.dll+0x526b1)
clang-18: error: linker command failed due to signal (use -v to see invocation)
@mstorsjo
Copy link
Owner

Thanks for the report, I've managed to reproduce it. I'll try to look into it a bit later.

mstorsjo added a commit to mstorsjo/llvm-project that referenced this issue Apr 12, 2024
@mstorsjo
[LLD] [COFF] Don't add pseudo relocs for dangling references
f6ea867 
When doing GC, we normally won't have dangling references, because
such a reference would keep the other section alive, keeping it
from being eliminated.

However, references within DWARF sections are ignored for the
purposes of GC (because otherwise, they would essentially keep
everything alive, defeating the point of the GC), see
c579a5b for more context.

Therefore, dangling relocations against discarded symbols are
ignored within DWARF sections (see maybeReportRelocationToDiscarded
in Chunks.cpp). Consequently, we also shouldn't create any
pseudo relocations for these cases, as we run into a null pointer
dereference when trying to generate the pseudo relocation info for it.

This fixes the downstream bug
mstorsjo/llvm-mingw#418, fixing crashes
on combinations with -ffunction-sections, -fdata-sections,
-Wl,--gc-sections and debug info.
@mstorsjo mstorsjo mentioned this issue Apr 12, 2024
Merged
@mstorsjo
Copy link
Owner

I posted a potential fix for this at llvm/llvm-project#88487.

mstorsjo added a commit to llvm/llvm-project that referenced this issue Apr 15, 2024
@mstorsjo
[LLD] [COFF] Don't add pseudo relocs for dangling references (#88487)
9c970d5 
When doing GC, we normally won't have dangling references, because such
a reference would keep the other section alive, keeping it from being
eliminated.

However, references within DWARF sections are ignored for the purposes
of GC (because otherwise, they would essentially keep everything alive,
defeating the point of the GC), see
c579a5b for more context.

Therefore, dangling relocations against discarded symbols are ignored
within DWARF sections (see maybeReportRelocationToDiscarded in
Chunks.cpp). Consequently, we also shouldn't create any pseudo
relocations for these cases, as we run into a null pointer dereference
when trying to generate the pseudo relocation info for it.

This fixes the downstream bug
mstorsjo/llvm-mingw#418, fixing crashes on
combinations with -ffunction-sections, -fdata-sections,
-Wl,--gc-sections and debug info.
llvmbot pushed a commit to llvmbot/llvm-project that referenced this issue Apr 15, 2024
@mstorsjo @llvmbot
[LLD] [COFF] Don't add pseudo relocs for dangling references (llvm#88487
e7e348a 
)

When doing GC, we normally won't have dangling references, because such
a reference would keep the other section alive, keeping it from being
eliminated.

However, references within DWARF sections are ignored for the purposes
of GC (because otherwise, they would essentially keep everything alive,
defeating the point of the GC), see
c579a5b for more context.

Therefore, dangling relocations against discarded symbols are ignored
within DWARF sections (see maybeReportRelocationToDiscarded in
Chunks.cpp). Consequently, we also shouldn't create any pseudo
relocations for these cases, as we run into a null pointer dereference
when trying to generate the pseudo relocation info for it.

This fixes the downstream bug
mstorsjo/llvm-mingw#418, fixing crashes on
combinations with -ffunction-sections, -fdata-sections,
-Wl,--gc-sections and debug info.

(cherry picked from commit 9c970d5)
aniplcc pushed a commit to aniplcc/llvm-project that referenced this issue Apr 15, 2024
@mstorsjo @aniplcc
[LLD] [COFF] Don't add pseudo relocs for dangling references (llvm#88487
5ec1196 
)

When doing GC, we normally won't have dangling references, because such
a reference would keep the other section alive, keeping it from being
eliminated.

However, references within DWARF sections are ignored for the purposes
of GC (because otherwise, they would essentially keep everything alive,
defeating the point of the GC), see
c579a5b for more context.

Therefore, dangling relocations against discarded symbols are ignored
within DWARF sections (see maybeReportRelocationToDiscarded in
Chunks.cpp). Consequently, we also shouldn't create any pseudo
relocations for these cases, as we run into a null pointer dereference
when trying to generate the pseudo relocation info for it.

This fixes the downstream bug
mstorsjo/llvm-mingw#418, fixing crashes on
combinations with -ffunction-sections, -fdata-sections,
-Wl,--gc-sections and debug info.
tstellar pushed a commit to llvmbot/llvm-project that referenced this issue Apr 16, 2024
@mstorsjo @tstellar
[LLD] [COFF] Don't add pseudo relocs for dangling references (llvm#88487
995539c 
)

When doing GC, we normally won't have dangling references, because such
a reference would keep the other section alive, keeping it from being
eliminated.

However, references within DWARF sections are ignored for the purposes
of GC (because otherwise, they would essentially keep everything alive,
defeating the point of the GC), see
c579a5b for more context.

Therefore, dangling relocations against discarded symbols are ignored
within DWARF sections (see maybeReportRelocationToDiscarded in
Chunks.cpp). Consequently, we also shouldn't create any pseudo
relocations for these cases, as we run into a null pointer dereference
when trying to generate the pseudo relocation info for it.

This fixes the downstream bug
mstorsjo/llvm-mingw#418, fixing crashes on
combinations with -ffunction-sections, -fdata-sections,
-Wl,--gc-sections and debug info.

(cherry picked from commit 9c970d5)
@mstorsjo
Copy link
Owner

This issue should have been fixed now, in https://github.com/mstorsjo/llvm-mingw/releases/tag/20240417.

@nidefawl
Copy link
Author

I can confirm this is fixed in the latest release. Thanks a lot!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
2 participants
@mstorsjo @nidefawl