Bug ID: JDK-4343963 hotspot dumps core on minor vm exits (e.g. mistyped library name)

Versions (Unresolved/Resolved/Fixed)

The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.

Other
1.3.0 sol-beta2Fixed

Due to the fix (which we badly needed) for 4336145, hotspot now dumps
core for any vm_exit_during_initialization even in product mode.
The problem was seen on Kestrel Solaris beta almost b17.

There are times when a core dump is not needed, and inappropriate.

The example found was in mistyping a library name, as in 
  java -Xrunlibreqevent008 reqevent008 instead of typing
  java -Xrunreqevent008 reqevent008

What I got back was:

Error occurred during initialization of VM
Could not find -Xrun library: liblibreqevent008.so
Abort (core dumped)

The request is to split errors into those where a core dump is helpful
and those where it is overkill.

CONVERTED DATA BugTraq+ Release Management Values COMMIT TO FIX: kest-sol-beta2 FIXED IN: kest-sol-beta2 INTEGRATED IN: kest-sol-beta2

14-06-2004

EVALUATION john.coomes@eng 2000-06-13 As mentioned in the description, a core dump from vm_exit_during_initialization() was an unintended side effect of the fix for 4336145. The most common reasons for vm_exit_during_initialization() and vm_exit_out_of_memory() to be called are user errors: - the max heap size is too small - the max heap size is smaller than the min heap size - a required native library is missing or corrupted (e.g., libzip.so) - a -Xrun library name is misspelled, not in the library path, or fails to initialize - not enough memory or swap space is available to create or extend the heap In all these cases a message is displayed to stdout explaining the problem. Dumping core appears to the user to be a bug in the vm.

11-06-2004

SUGGESTED FIX john.coomes@eng 2000-06-13 All the variants of vm_exit_during_initialization(), as well as vm_exit_out_of_memory(), call vm_abort() in java.cpp, which in turn calls os::abort(). In product builds, change the call to be os::abort(false). *** ./src/share/vm/runtime/java.cpp-1.142 Tue Jun 13 15:17:41 2000 --- ./src/share/vm/runtime/java.cpp Fri Jun 9 11:16:54 2000 *************** *** 347,353 **** ((JavaThread*)thread)->set_thread_state(_thread_in_native); } } ! os::abort(); ShouldNotReachHere(); } --- 347,353 ---- ((JavaThread*)thread)->set_thread_state(_thread_in_native); } } ! os::abort(PRODUCT_ONLY(false)); // No core dump in product build. ShouldNotReachHere(); }

11-06-2004

Relates :	JDK-4651918 - Core dump with non existing runlibrary
Relates :	JDK-6644629 - JVM dies with little/misleading problem information during excessive creation of ORB threads
Relates :	JDK-4651882 - Core dump with bogus bootclasspath
Relates :	JDK-6694099 - Hotspot vm_exit_out_of_memory should dump core
Relates :	JDK-4418494 - test nsk/regression/b4343963 crashes java_g VM