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

[Michael Spencer]

On Jan 27, 2015 9:16 PM, "Reid Kleckner" <rnk at google.com> wrote:
>
> In theory, I am happy to suppress more dialog boxes more often. In
practice, suppressing the dialog often prevents our stack dumper from
kicking in. If you can try to preserve any stack dumping we have, then
yeah, let's turn them off unconditionally. :)
>
> 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.
>

It's actually not global. It's per image. Setting it in the dll doesn't
change what happens when the main app crashes. Same for the other
direction.
My main concern is a user of lib lto that doesn't have stderr hooked up
anywhere. If we don't have that, then i don't really see a problem.

> On Tue, Jan 27, 2015 at 10:40 AM, Michael Spencer <bigcheesegs at gmail.com>
wrote:
>>
>> We have multiple different places where we handle dialog box
>> suppression to various degrees. I recently discovered another place we
>> need to do it, and so I wanted to unify all of them.
>>
>> We currently have most of this suppression logic behind the
>> LLVM_DISABLE_CRASH_REPORT environment variable. I would like to make
>> it unconditional. I don't believe we have any users that desire the
>> dialog box behavior, as all of our tools are used via the command line
>> and can report crashes via stderr.
>>
>> I wanted to check with other Windows users/vendors for exactly which
>> behavior they wanted.
>>
>> The case where I need to add it now is the lto shared library. The CRT
>> crash reporting state doesn't seem to be replicated across DLL
>> boundaries, so the main application can't actually control this
>> currently. Should we unconditionally disable here? or add an API to
>> control it?
>>
>> - Michael Spencer
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20150127/099454c2/attachment.html>