Description
One of the failures in JDK-8156223 is a SIGSEGV, but no hs_err file is produced, and the WatcherThread reports:
[ timer expired, abort... ]
I looked at the core file and the crashing thread had crashed while doing a malloc. The signal handler called VMError::report_and_die(), which eventually leads to another malloc(), which seems to be deadlocked. Most likely the first malloc is holding a (non-reentrant) lock that the 2nd malloc also wants to grab.
Moral of the story is we need to be careful about what type of services we rely on after we catch a crash originating from libc or OS code. We might need a timer in VMError to quickly timeout and move to the next stage before the WatcherThread times out.
[ timer expired, abort... ]
I looked at the core file and the crashing thread had crashed while doing a malloc. The signal handler called VMError::report_and_die(), which eventually leads to another malloc(), which seems to be deadlocked. Most likely the first malloc is holding a (non-reentrant) lock that the 2nd malloc also wants to grab.
Moral of the story is we need to be careful about what type of services we rely on after we catch a crash originating from libc or OS code. We might need a timer in VMError to quickly timeout and move to the next stage before the WatcherThread times out.
Attachments
Issue Links
- relates to
-
JDK-8176140 Crashes or timeouts during error reporting may lead to infinitely repeated error logs until ErrorLogTimeout is hit
-
- Resolved
-
-
JDK-8166944 Hanging Error Reporting steps may lead to torn error logs.
-
- Resolved
-