[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