[PATCH] D88348: [LLD][COFF] When using LLD-as-a-library, always prevent re-entrance on failures
Alexandre Ganea via Phabricator via llvm-commits
llvm-commits at lists.llvm.org
Mon Sep 28 18:16:17 PDT 2020
aganea added a comment.
In D88348#2299620 <https://reviews.llvm.org/D88348#2299620>, @MaskRay wrote:
> I have seen this in a language server. It seems that CrashRecoveryContext does not (correctly) use sigaltstack(). With sigaltstack, we can recover after a stack overflow.
Good to know at least it could work on Linux. I wanted to activate coverage for this at some point in D74229 <https://reviews.llvm.org/D74229> but then it wasn't working on Debug builds on Windows. I'll need to get back to it.
> For the stack overflow you observed, how did that happen?
The stack overflow happens in the first place somewhere in the Windows CRT while releasing heap blocks. This is rare, as it depends on the random pattern that was in memory at the location of `ObjFile::dwarf` when `fatal()` was called by `ELFFileBase::init()`.
> In D88348#2299551 <https://reviews.llvm.org/D88348#2299551>, @rnk wrote:
>
>> I think I'm OK with the functional change, but I think I would prefer not to keep the code that buffers stdout/stderr for the lit test. I think the complexity/size cost outweighs the test benefit.
>
> I share the same feeling. Hope `bufferedStdout` can be avoided
I'll try to find another way. The issue is that we're blocking stdout/stderr on all iterations, but the last one. Which doesn't work if `fatal()` occurs in the first iteration (as expected, in a test). Perhaps I could simply set LLD_IN_TEST=1 for tests that expect `fatal()` or a crash.
Repository:
rG LLVM Github Monorepo
CHANGES SINCE LAST ACTION
https://reviews.llvm.org/D88348/new/
https://reviews.llvm.org/D88348
More information about the llvm-commits
mailing list