[PATCH] D119009: [Support] Ensure handlers are set up before printing the stacktrace

[Pavel Labath via Phabricator via llvm-commits]

labath added a comment.

In D119009#3302354 <https://reviews.llvm.org/D119009#3302354>, @JDevlieghere wrote:

> I believe it's generally considered bad practice to install signal handlers in a library. This is why the initialization currently happens in the driver. If you look at other tools in LLVM you'll notice they do the same thing.
>
> Can we address this issue by (1) making sure we don't crash in lldbassert when calling `PrintStackTrace` without having initialized the signal handlers and (2) providing the ability to install the signal handlers through the SB API (if that doesn't already exist) if the user of libLLDB wants this functionality?

I think that's a very good approach to the problem.

That said, I want to add that, as far as I can tell, the windows-specific initialization is not actually an issue here. Loading a dll does not have the same global impact as installing a signal handler (if the dll is well-behaved, anyway). So, I can imagine a setup (though I don't know how it would work in detail) where where we initialize the windows-specific parts of this from within lldb, but avoid the parts which installs handlers on other platforms.

I guess it might be interesting to know how is this situation handled for other out-of-tree users of llvm libraries on windows (assuming we have any). Do they get this to work somehow, or is lldb the first one to want to print a backtrace in a non-fatal situation (the non-fatal lldbasserts are definitely... unique).

(I am assuming people won't notice the difference between a crash because the app hit a real assertion failure, or because it failed to print the backtrace of that failure, if they don't know that they should expect to see that backtrace.)


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D119009/new/

https://reviews.llvm.org/D119009