45b8a741fb
This is a follow-up for D70378 (Cover usage of LLD as a library). While debugging an intermittent failure on a bot, I recalled this scenario which causes the issue: 1.When executing lld/test/ELF/invalid/symtab-sh-info.s L45, we reach lld::elf::Obj-File::ObjFile() which goes straight into its base ELFFileBase(), then ELFFileBase::init(). 2.At that point fatal() is thrown in lld/ELF/InputFiles.cpp L381, leaving a half-initialized ObjFile instance. 3.We then end up in lld::exitLld() and since we are running with LLD_IN_TEST, we hapily restore the control flow to CrashRecoveryContext::RunSafely() then back in lld::safeLldMain(). 4.Before this patch, we called errorHandler().reset() just after, and this attempted to reset the associated SpecificAlloc<ObjFile<ELF64LE>>. That tried to free the half-initialized ObjFile instance, and more precisely its ObjFile::dwarf member. Sometimes that worked, sometimes it failed and was catched by the CrashRecoveryContext. This scenario was the reason we called errorHandler().reset() through a CrashRecoveryContext. But in some rare cases, the above repro somehow corrupted the heap, creating a stack overflow. When the CrashRecoveryContext's filter (that is, __except (ExceptionFilter(GetExceptionInformation()))) tried to handle the exception, it crashed again since the stack was exhausted -- and that took the whole application down. That is the issue seen on the bot. Locally it happens about 1 times out of 15. Now this situation can happen anywhere in LLD. Since catching stack overflows is not a reliable scenario ATM when using CrashRecoveryContext, we're now preventing further re-entrance when such failures occur, by signaling lld::SafeReturn::canRunAgain=false. When running with LLD_IN_TEST=2 (or above), only one iteration will be executed, instead of two. Differential Revision: https://reviews.llvm.org/D88348
39 lines
1.5 KiB
ArmAsm
39 lines
1.5 KiB
ArmAsm
# REQUIRES: x86
|
|
|
|
# RUN: llvm-mc -filetype=obj -triple=x86_64-windows-msvc -o %t.main.obj %s
|
|
|
|
# RUN: llvm-mc -filetype=obj -triple=x86_64-windows-msvc -o %t.lib.obj \
|
|
# RUN: %S/Inputs/mangled-symbol.s
|
|
# RUN: lld-link /lib /out:%t.lib %t.lib.obj
|
|
# RUN: lld-link /lib /llvmlibthin /out:%t_thin.lib %t.lib.obj
|
|
|
|
# RUN: lld-link /entry:main %t.main.obj %t.lib /out:%t.exe 2>&1 | \
|
|
# RUN: FileCheck --allow-empty %s
|
|
# RUN: lld-link /entry:main %t.main.obj %t_thin.lib /out:%t.exe 2>&1 | \
|
|
# RUN: FileCheck --allow-empty %s
|
|
# RUN: lld-link /entry:main %t.main.obj /wholearchive:%t_thin.lib /out:%t.exe 2>&1 | \
|
|
# RUN: FileCheck --allow-empty %s
|
|
|
|
# RUN: rm %t.lib.obj
|
|
# RUN: lld-link /entry:main %t.main.obj %t.lib /out:%t.exe 2>&1 | \
|
|
# RUN: FileCheck --allow-empty %s
|
|
# RUN: env LLD_IN_TEST=1 not lld-link /entry:main %t.main.obj %t_thin.lib \
|
|
# RUN: /out:%t.exe 2>&1 | FileCheck --check-prefix=NOOBJ %s
|
|
# RUN: env LLD_IN_TEST=1 not lld-link /entry:main %t.main.obj %t_thin.lib /out:%t.exe \
|
|
# RUN: /demangle:no 2>&1 | FileCheck --check-prefix=NOOBJNODEMANGLE %s
|
|
|
|
# CHECK-NOT: error: could not get the buffer for the member defining
|
|
# NOOBJ: error: could not get the buffer for the member defining symbol int __cdecl f(void): {{.*}}.lib({{.*}}.lib.obj):
|
|
# NOOBJNODEMANGLE: error: could not get the buffer for the member defining symbol ?f@@YAHXZ: {{.*}}.lib({{.*}}.lib.obj):
|
|
|
|
.text
|
|
|
|
.def main
|
|
.scl 2
|
|
.type 32
|
|
.endef
|
|
.global main
|
|
main:
|
|
call "?f@@YAHXZ"
|
|
retq $0
|