United StatesChange Country, Oracle Worldwide Web Sites Communities I am a... I want to...
Bug ID: JDK-7141259 Native stack is missing in hs_err
JDK-7141259 : Native stack is missing in hs_err

Details
Type:
Bug
Submit Date:
2012-01-31
Status:
Closed
Updated Date:
2012-03-24
Project Name:
JDK
Resolved Date:
2012-03-24
Component:
hotspot
OS:
generic
Sub-Component:
runtime
CPU:
generic
Priority:
P2
Resolution:
Fixed
Affected Versions:
hs23
Fixed Versions:
hs23 (b16)

Related Reports
Backport:
Backport:
Relates:
Relates:

Sub Tasks

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

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
                                     
2012-02-01
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.
                                     
2012-02-01
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.
                                     
2012-02-02
EVALUATION

http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/db006a85bf91
                                     
2012-02-09
EVALUATION

http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/db006a85bf91
                                     
2012-02-17
EVALUATION

http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/db006a85bf91
                                     
2012-02-18
EVALUATION

http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/db006a85bf91
                                     
2012-02-18
EVALUATION

http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/db006a85bf91
                                     
2012-03-22



Hardware and Software, Engineered to Work Together