en Copyright 2015 Java http://172.16.0.5:8080/history/llvm-project-15.0.7/lld/test/COFF/thunk-replace.s#45b8a741 [LLD][COFF] When using LLD-as-a-library, always prevent re-entrance on failuresThis 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 whichcauses 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 theCrashRecoveryContext. This scenario was the reason we callederrorHandler().reset() through a CrashRecoveryContext.But in some rare cases, the above repro somehow corrupted the heap, creating astack overflow. When the CrashRecoveryContext's filter (that is,__except (ExceptionFilter(GetExceptionInformation()))) tried to handle theexception, it crashed again since the stack was exhausted -- and that took thewhole application down. That is the issue seen on the bot. Locally it happensabout 1 times out of 15.Now this situation can happen anywhere in LLD. Since catching stack overflows isnot a reliable scenario ATM when using CrashRecoveryContext, we're nowpreventing further re-entrance when such failures occur, by signalinglld::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 List of files: /llvm-project-15.0.7/lld/test/COFF/thunk-replace.s Thu, 12 Nov 2020 13:14:20 +0000 Alexandre Ganea <alexandre.ganea@ubisoft.com> http://172.16.0.5:8080/history/llvm-project-15.0.7/lld/test/COFF/thunk-replace.s#474be005 [COFF] Store import symbol pointers as pointers to the base classFuture symbol insertions can potentially change the type of thesesymbols - keep pointers to the base class to reflect this, anduse dynamic casts to inspect them before using as the subclasstype.This fixes crashes that were possible before, by touching thesesymbols that now are populated as e.g. a DefinedRegular, viathe old pointers with DefinedImportThunk type.Differential Revision: https://reviews.llvm.org/D48953llvm-svn: 336652 List of files: /llvm-project-15.0.7/lld/test/COFF/thunk-replace.s Tue, 10 Jul 2018 10:40:11 +0000 Martin Storsjo <martin@martin.st>