JDK-6300358 : JVM abort with Full thread dump by kill -QUIT
  • Type: Bug
  • Component: hotspot
  • Sub-Component: runtime
  • Affected Version: 1.4.1_03,5.0u4
  • Priority: P4
  • Status: Closed
  • Resolution: Fixed
  • OS: solaris_9
  • CPU: sparc
  • Submitted: 2005-07-21
  • Updated: 2014-02-27
  • Resolved: 2006-06-26
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 JDK 6
1.4.2_13 b01Fixed 6Fixed
Related Reports
Relates :  
Relates :  
Description
A customer have found out JVM abort with Full thread dump by kill -QUIT.

CONFIGURATION : 
  OS  : Solaris 9
  JDK : 1.4.1_03
 

STACK TRACE :
.....
 Thread 37 (thread 40 (d74b0e00) lwp 40):
#0  0xff29f8e4 in ___lwp_mutex_lock from /usr/lib/libc.so.1
#1  0xfea6bc70 in void Mutex::wait_for_lock_blocking_implementation(JavaThread*)
#2  0xfe8e2bac in void Mutex::lock()
#3  0xfe9434a4 in HeapWord*TwoGenerationCollectorPolicy::mem_allocate_work(unsigned,int,int)
#4  0xfe93918c in instanceOopDesc*instanceKlass::allocate_instance(Thread*)
#5  0xfed2a680 in void JavaThread::allocate_threadObj(Handle,char*,int,Thread*)
#6  0xfec23adc in attach_current_thread
#7  0xd6c914c0 in Call_Java
    ....
#8  <signal handler called>
#9  0xff2344e4 in strlen from root/usr/lib/libc.so.1
#10 0xff286bec in _doprnt from root/usr/lib/libc.so.1
#11 0xff288c30 in vsnprintf from root/usr/lib/libc.so.1
#12 0xfe9d5720 in void outputStream::print(const char*,...)
#13 0xfed2e834 in void Threads::print(int,int)
#14 0xfea594b8 in void VM_Operation::evaluate()
#15 0xfea58e04 in void VMThread::evaluate_operation(VM_Operation*)
#16 0xfeb2d820 in void VMThread::loop()
.....


INVESTIGATION :

According to the above stack trace,

 1. Thread37 information seems to show  the thread executes AttachCurrentThread and try to allocate 
    an area for java.lang.Thread.
 2. VMThread tries to output Full thread dump. When the thread output thename of  above user thread 
    at the above, it access to 0.


Considering to the source code, 
  - JavaThread::get_thread_name() returns NULL.
  - Program tries to execute 
      tty->print("\"%s\" ", get_thread_name());
    Because get_thread_name() is NULL, the program access to 0 address and
    abnormal end is caused.


---- hotspot/src/share/vm/runtime/thread.cpp
.....
const char* JavaThread::get_thread_name() const {
  // Early safepoints hit while JavaThread::current does not yet have TLS
  debug_only(if (!(SafepointSynchronize::is_at_safepoint()
    || JavaThread::current() == this)) assert_locked_or_safepoint(Threads_lock);)
  oop thread_obj = threadObj();
  if (thread_obj != NULL) {
    typeArrayOop name = java_lang_Thread::name(thread_obj);
    const char* str = UNICODE::as_utf8((jchar*) name->base(T_CHAR), name->length());
    return str;
  } else {
    return NULL;
  }
  return NULL;
}

.....
void JavaThread::print() {
  tty->print("\"%s\" ", get_thread_name());
  if (threadObj() != NULL && java_lang_Thread::is_daemon(threadObj()))  tty->print("daemon ");
  Thread::print();
  // print guess for valid stack memory region (assume 4K pages); helps lock debugging
  tty->print_cr("[%lx..%lx]", (intptr_t)last_Java_sp() & ~right_n_bits(12), highest_lock());
#ifndef PRODUCT
  print_thread_state();
  _safepoint_state->print();
#endif // PRODUCT
}
###@###.### 2005-07-21 22:40:36 GMT

Comments
EVALUATION Following fix integrated in 1.4.2_13 b01: http://jpsesvr.sfbay.sun.com:8080/ctetools/html/ViewDetail.jsp?index=1766
13-04-2006