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

[Thomas Stüfe]

Hi Christian,

thanks for that info!

Thomas

On Wed, Mar 11, 2015 at 12:56 PM, Christian Tornqvist <
christian.tornqvist at oracle.com> wrote:

> 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
> >>
>
>
>