United StatesChange Country, Oracle Worldwide Web Sites Communities I am a... I want to...
Bug ID: JDK-6300358 JVM abort with Full thread dump by kill -QUIT
JDK-6300358 : JVM abort with Full thread dump by kill -QUIT

Details
Type:
Bug
Submit Date:
2005-07-21
Status:
Closed
Updated Date:
2014-02-27
Project Name:
JDK
Resolved Date:
2006-06-26
Component:
hotspot
OS:
solaris_9
Sub-Component:
runtime
CPU:
sparc
Priority:
P4
Resolution:
Fixed
Affected Versions:
1.4.1_03,5.0u4
Fixed Versions:
1.4.2_13 (b01)

Related Reports
Backport:
Backport:
Relates:
Relates:

Sub Tasks

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
                                     
2006-04-13



Hardware and Software, Engineered to Work Together