JDK-6504660 : HPI panic callback is dead code
  • Type: Bug
  • Component: core-svc
  • Sub-Component: debugger
  • Affected Version: 7,8
  • Priority: P4
  • Status: Resolved
  • Resolution: Fixed
  • OS: generic
  • CPU: generic
  • Submitted: 2006-12-14
  • Updated: 2019-03-19
  • Resolved: 2019-03-13
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.
JDK 13
13 b12Fixed
Related Reports
Relates :  
JDK-6341237 - JVM 1.4.2_08 crashes on RHL AS 3.0
Relates :  
JDK-6626677 - Error: Unimplemented()/HPI sysMonitorExit is broken on linux
Relates :  
JDK-6502237 - HPI sysMonitorExit is broken on linux-amd64
Description
In the fastdebug and debug builds, libhpi.so may call our HPI panic() callback during a sysAssert() failure.  Currently the callback is unimplemented and results in a call to Unimplemented(), masking the true cause of the failure.  We should provide an implementation for the sake of better error reporting.

For further background see bug JDK-6502237.
I don't think hpi should call back to the VM to die anyway, but call regular unix assert, but we should give an error and add that the bug is in hpi not the VM.

This is annoying that so many linux tests intermittently fail with this hpi bug.
I changed this hpi_panic from Unimplemented() crash to a warning(Unimplemented) because bug number 6626677 was affecting testing.  This is safe for this particular bug anyway.

As part of this fix, the crash should be restored in the VM for jdk7 only (there's apparently a gate we have in the vm) after bug 6626677 is fixed.  If the jdk fix is backported to jdk 6 we can enable the crash unconditionally in the VM, but after HS13.
Comments
That's what the patch does.
07-03-2019
As David pointed out, the only use of panic() in JDWP is within "#ifndef NATIVE", which is there to support the now defunct green threads support. We should remove the NATIVE related #ifdefs and #ifndefs, and only keep the code within the "#ifdef NATIVE" parts.
07-03-2019
The remaining code that need to be cleaned up is in the JDWP agent so moving this to core-svc/debgger.
07-03-2019
Re-assigning to hotspot/runtime.
12-12-2016
Sorry Chris but the code in question is in the JDK not hotspot - assigning back to core-libs.
12-12-2016
The dead code still exists in 9 as previously listed. I have removed the 9-na label.
01-12-2016
The hotspot function is long gone. This should be reassigned to the core-libs team to see if they want to remove this dead code.
27-02-2015
The only reference to a potential panic routine seems to be in dead code that is not built (this exists in 7, 8 and 9): ./java.base/unix/native/libjava/java_props_md.c:/* This function gets called very early, before VM_CALLS are setup. ./java.base/unix/native/libjava/java_props_md.c: * Do not use any of the VM_CALLS entries!!! ./jdk.jdwp.agent/unix/native/libjdwp/linker_md.c: VM_CALL(panic)("libthread loaded into green threads"); In 7 and 8 the call is in: ./solaris/back/linker_md.c: VM_CALL(panic)("libthread loaded into green threads"); but note there is no definition of VM_CALL anywhere. The usage is in a dead ifdef based on !NATIVE - where NATIVE is explicitly defined in the source file. This is prehistoric green threads leftovers that should be removed from the JDK code.
24-02-2015
EVALUATION I think the JDK still calls this, just not through the HPI layer, contrary to the name.
17-09-2012
EVALUATION Now that HPI has been removed from HotSpot via: 6348631 4/2 remove the use of the HPI library from Hotspot I think this bug can be closed as "will not fix". I'll double check with Coleen...
11-02-2011