RFR(S): 8074354: tests that intentionally crash the VM can timeout creating a core file
thomas.stuefe at gmail.com
Wed Mar 11 11:39:18 UTC 2015
On Wed, Mar 11, 2015 at 12:18 PM, Staffan Larsen <staffan.larsen at oracle.com>
> > 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
For our support error logs are more important than minidumps. Customers
usually send error logs, almost never cores, and if they do, they are
difficult to work with. Also on Windows, we found anything but full dumps
(including all memory) of little use, but full dumps can get very big.
But I can see that this may be different for your work.
At some point we decided to just revert the order of error log and mini
dump. So we pay the price of MiniDumps being a little more removed from the
crash point (like they are on Unix), and get more reliably error logs which
are closer to the crash point.
And for cases where we really want a good core, we added an option
"-XX:+ImmediateCoreOnError", which just cores right away when an error
happens instead of calling VmError::report_and_die(). That works on Unix
A nice side effect about our solution is that all platforms behave
> When does MiniDumpWriteDump hang infinitly?
I do not know. Had several cases of hanging tests on various machines.
Process was hanging in MiniDumpWriteDump() and did not return. Debugging
revealed nothing in particular.
Seems to be a known issue, if you google around, you find reports of
MiniDumpWriteDump freezing but no solution. It may depend on the
dbghelp.dll version but that is out of our hands at the customer sites.
> > So, I would like to see os::abort on Windows call MiniDumpWriteDump(),
> > 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
> >> Windows and the latter for all platforms. When VM crashes on non
> >> core file generated as default if OS sets core dump allowed. Default
> >> of CreateCoredumpOnCrash set to 'true' to keep same behavior on non
> >> 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
> >> but only as alias for the new flag.
> >> Tests: JPRT, manual tests setting CreateMinidumpOnCrash on commandline
> >> verify flag change as alias.
> >> Thanks
> >> Yumin
More information about the hotspot-runtime-dev