mirror of
https://github.com/capstone-engine/llvm-capstone.git
synced 2025-01-16 13:08:42 +00:00
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:🧝: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
48 lines
1.5 KiB
Plaintext
48 lines
1.5 KiB
Plaintext
# RUN: mkdir -p %t.dir
|
|
# RUN: yaml2obj %p/Inputs/delayimports-error.yaml -o %t1.obj
|
|
# RUN: lld-link /out:%t.dir/foo.dll /dll %t1.obj /export:datasym,DATA /noentry
|
|
|
|
# RUN: yaml2obj %s -o %t2.obj
|
|
# RUN: env LLD_IN_TEST=1 not lld-link /out:%t.exe /entry:main %t2.obj \
|
|
# RUN: %t.dir/foo.lib /delayload:foo.dll \
|
|
# RUN: /alternatename:__delayLoadHelper2=main /opt:noref >& %t.log
|
|
# RUN: FileCheck %s < %t.log
|
|
|
|
# CHECK: cannot delay-load foo.dll due to import of data: __declspec(dllimport) datasym
|
|
|
|
--- !COFF
|
|
header:
|
|
Machine: IMAGE_FILE_MACHINE_AMD64
|
|
Characteristics: []
|
|
sections:
|
|
- Name: .text
|
|
Characteristics: [ IMAGE_SCN_CNT_CODE, IMAGE_SCN_MEM_EXECUTE, IMAGE_SCN_MEM_READ ]
|
|
Alignment: 16
|
|
SectionData: 0000000000000000
|
|
symbols:
|
|
- Name: .text
|
|
Value: 0
|
|
SectionNumber: 1
|
|
SimpleType: IMAGE_SYM_TYPE_NULL
|
|
ComplexType: IMAGE_SYM_DTYPE_NULL
|
|
StorageClass: IMAGE_SYM_CLASS_STATIC
|
|
SectionDefinition:
|
|
Length: 8
|
|
NumberOfRelocations: 0
|
|
NumberOfLinenumbers: 0
|
|
CheckSum: 0
|
|
Number: 0
|
|
- Name: main
|
|
Value: 0
|
|
SectionNumber: 1
|
|
SimpleType: IMAGE_SYM_TYPE_NULL
|
|
ComplexType: IMAGE_SYM_DTYPE_FUNCTION
|
|
StorageClass: IMAGE_SYM_CLASS_EXTERNAL
|
|
- Name: __imp_datasym
|
|
Value: 0
|
|
SectionNumber: 0
|
|
SimpleType: IMAGE_SYM_TYPE_NULL
|
|
ComplexType: IMAGE_SYM_DTYPE_NULL
|
|
StorageClass: IMAGE_SYM_CLASS_EXTERNAL
|
|
...
|