gregbedwell
commented
7 years ago I'm not sure of the best way to deal with this. For clang, we could probably modify the strategy so that the driver process is responsible for creating minidumps for spawned processes that crash. There'd be some benefit to this as we could do this at the same time that we create the other reproducer files so they could all share the same random character suffix, be reported together, etc. This doesn't help processes that aren't spawned by some driver though. I'm not sure we can trust a crashed process to reliably spawn a subprocess to deal with this either. We should likely look into fixing the use-case from Bug 33854 at the same time if we change this.
As a sidenote, we've found minidump writing useful for triaging bugs that don't reproduce in a reliable manner so I don't want to lose the feature altogether. I've been meaning to send a patch up to improve the flags we set for minidump writing as I've found we can decently improve the amount of useful information for a relatively minimal size impact.
Extended Description
Use of PrintStackTraceOnErrorSignal (/Support/Signals.h) can cause hangs due to the call of MiniDumpWriteDump when an exception is unhandled.
From the MiniDumpWriteDump description:
"MiniDumpWriteDump should be called from a separate process if at all possible, rather than from within the target process being dumped. This is especially true when the target process is already not stable. For example, if it just crashed. A loader deadlock is one of many potential side effects of calling MiniDumpWriteDump from within the target process"
https://msdn.microsoft.com/en-us/library/windows/desktop/ms680360(v=vs.85).aspx