RFR(S): 8074354: tests that intentionally crash the VM can timeout creating a core file

[Christian Tornqvist]

Hi Staffan, 

>When does MiniDumpWriteDump hang infinitly?

This can happen if we crash when someone is holding the process wide LdrpLoaderLock lock. Dbghelp.dll will try to load other libraries (version.dll and others) and will end up hanging waiting for the lock to be released. 

https://bugs.openjdk.java.net/browse/JDK-8051995 has more info on this.

Thanks,
Christian

-----Original Message-----
From: hotspot-runtime-dev [mailto:hotspot-runtime-dev-bounces at openjdk.java.net] On Behalf Of Staffan Larsen
Sent: Wednesday, March 11, 2015 7:19 AM
To: Thomas Stüfe
Cc: hotspot-runtime-dev at openjdk.java.net
Subject: Re: RFR(S): 8074354: tests that intentionally crash the VM can timeout creating a core file


> On 11 mar 2015, at 11:47, Thomas Stüfe <thomas.stuefe at gmail.com> wrote:
> 
> Hi Yumin,
> 
> There is also test/runtime/ErrorHandling/SecondaryErrorTest.java - 
> could you please add "-XX:-CreateCoredumpOnCrash" ? Thank you!
> 
> Beyond that, as I wrote in the bug report comments:
> 
> "This is also a problem on Windows - MiniDumpWriteDump() may hang 
> infinitly. And on Windows this is worse than under UNIX because we 
> create the Dump before writing the hs-err file, so if the Dump hangs, 
> we get no error log. I would like to revert the order: create the 
> minidump after writing the error log, the same way Unix does it. We 
> did this in our JVM
> (SAP) because for us, error logs are more useful than minidumps. “

The reason the order is what it is is for the minidump to have the most relevant context regarding the failure. If we run the error log writing before writing the minidump, then the state of the VM has changed since the failure occurred and the minidump will have less value. Only windows provides the possibility to do this which is why it is only this way on windows. 

When does MiniDumpWriteDump hang infinitly?

/Staffan


> 
> So, I would like to see os::abort on Windows call MiniDumpWriteDump(), 
> and thus the mini dump writing moved after the error log writing. This 
> would also make the code way cleaner because the control flow would be 
> the same on all platforms.
> 
> I understand that this may be out of scope for your change, but I 
> would like to know what others think about this.
> 
> Kind regards, Thomas
> 
> 
> 
> 
> 
> 
> 
> On Wed, Mar 11, 2015 at 8:02 AM, Yumin Qi <yumin.qi at oracle.com> wrote:
> 
>> Please review:
>> 
>> bug: https://bugs.openjdk.java.net/browse/JDK-8074354
>> webrev: http://cr.openjdk.java.net/~minqi/8074354/webrev01/
>> 
>> Summary: Tests timed out when VM crashes and dumping core file which 
>> in the test case is not needed. To make core not created, the fix 
>> changed CreateMinidumpOnCrash to CreateCoredumpOnCrash, the former is 
>> only used on Windows and the latter for all platforms. When VM 
>> crashes on non Windows, core file generated as default if OS sets 
>> core dump allowed. Default value of CreateCoredumpOnCrash set to 
>> 'true' to keep same behavior on non Windows platforms, but changed 
>> for Windows --- original is false, not create minidump on Windows. 
>> With CreateCoredumpOnCrash turned off, no core file will be 
>> generated. CreateMinidumpOnCrash still can be used on commandline but only as alias for the new flag.
>> 
>> Tests: JPRT, manual tests setting CreateMinidumpOnCrash on 
>> commandline to verify flag change as alias.
>> 
>> Thanks
>> Yumin
>>