[LLVMdev] [Windows] Cleaning up dialog box suppression code.

Greg Bedwell gregbedwell at gmail.com
Tue Jan 27 14:14:37 PST 2015


>
> I am concerned about disabling crash diagnostics inside lib LTO. We don't
> generally call the signal setup code outside main. I'd like to understand
> why you need to change global settings like this from a library before
> doing it.
>

On the PS4 toolchain we're using LTO.dll called from an LTO process via
LoadLibrary.  Despite setting all of the various flags you need to do to
prevent pop-up boxes on Windows from the calling process it's having no
effect in suppressing the evil modal boxes from crashes/aborts coming from
inside the dll.  We also verified with a very simple testcase of a process
loading a dll that aborts that the settings do not appear to apply across
dlls (in either direction).  This area is not particularly well documented
though if anyone has a better way to achieve this.

The question is whether there is ever going to be any case where having a
modal dialog pop up is actually desirable behavior?  Certainly one bad
crash bug in clang or LTO would be capable of bringing the entire PS4
compiler testing pool to a grinding halt until someone manually went into
each of our boxes and clicked a button to close the box (and the same would
happen for any of our users who hit one on their own automated game
builds).  For that reason we've been disabling all the crash dialogs
unconditionally for PS4 since the beginning.

On a related note, I'm sitting on a local change that I'll start a
discussion on soon that will automatically write Windows minidumps without
any form of dialog box required so that we can do post-mortem debugging
when just the stack-trace isn't enough.  This is a more intrusive change
though, so I imagine that one will have to be opt-in via a config setting
though.

-Greg
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20150127/965e7f4e/attachment.html>


More information about the llvm-dev mailing list