JDK-7141259 : Native stack is missing in hs_err
  • Type: Bug
  • Component: hotspot
  • Sub-Component: runtime
  • Affected Version: hs23
  • Priority: P2
  • Status: Closed
  • Resolution: Fixed
  • OS: generic
  • CPU: generic
  • Submitted: 2012-01-31
  • Updated: 2022-11-25
  • Resolved: 2012-03-24
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 7 JDK 8 Other
7u4Fixed 8Fixed hs23Fixed
Related Reports
Duplicate :  
JDK-8077396 - Jetty crashed vm with message "unimplemented bytecode"
Relates :  
JDK-8297657 - name demangling intermittently fails
Relates :  
JDK-7120448 - Fix FP values for compiled frames in frame::describe
Relates :  
JDK-7071311 - Decoder enhancement
Description
Problematic frame and native stack are sometimes missing in hs_err with fastdebug build starting HS23 b11 (both on sparc and x86).
"error occurred during error reporting (printing problematic frame), id 0xe0000000" is reported.
Comments
EVALUATION http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/db006a85bf91
22-03-2012
EVALUATION http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/db006a85bf91
18-02-2012
EVALUATION http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/db006a85bf91
18-02-2012
EVALUATION http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/db006a85bf91
17-02-2012
EVALUATION http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/db006a85bf91
09-02-2012
EVALUATION The assert is simply highlighting the problem - that we are using locking code (and transitively a bunch of other VM code) from a signal handler, that is potentially in a reentrant context. Even if we skip the failing assert we are still doing the wrong thing here.
02-02-2012
EVALUATION It is something related to lock, but not ordering issue. The SGEV signal handler triggers decoder locking code, and hits following paranoid checking in Thread::current(), as decoder is executing on signal handler thread. inline Thread* Thread::current() { #ifdef ASSERT // This function is very high traffic. Define PARANOID to enable expensive // asserts. #ifdef PARANOID // Signal handler should call ThreadLocalStorage::get_thread_slow() Thread* t = ThreadLocalStorage::get_thread_slow(); assert(t != NULL && !t->is_inside_signal_handler(), "Don't use Thread::current() inside signal handler"); #endif #endif Thread* thread = ThreadLocalStorage::thread(); assert(thread != NULL, "just checking"); return thread; } So, it is not reproducible on product build.
01-02-2012
EVALUATION Also reproducible on Linux, I believe it is a locking problem as pointed out. I encountered the locking issue on my NMT repo. On 1/31/2012 6:11 PM, David Holmes wrote: > I'm looking at the decoder changes again and I don't think we can necessarily use the decoder_lock given an arbitrary failure point which could include being in the middle of using another lock. There may be guarantees and/or assertions that won't hold. > > Just a thought ... > > David
01-02-2012