Java Process terminates with the following messages.

#
# HotSpot Virtual Machine Error, Internal Error
# Please report this error to FUJITSU
#
# Java VM: Java HotSpot(TM) Server VM (1.4.2_FUJITSU_MODIFIED-B10 mixed mode)
#
# Fatal: Deadlock in safepoint code. stopped at 0x00000000
#
# Error ID: 53414645504F494E540E4350500159
#
# Problematic Thread: prio=5 tid=0x0032eb28 nid=0x1d runnable


The customer who has sent look into the core file and sent the following
report.

====== Customer Investigation ========

Problem thread is 0x21e8c0.

(gdb) f 8
#8 0xfea63cec in jni_FindClass
   from root/opt/jbk/jre14/lib/sparc/fjvm/libjvm.so
(gdb) x /8i 0xfea63cd0
0xfea63cd0 <jni_FindClass+144>: sethi %hi(0x80010000), %g3
0xfea63cd4 <jni_FindClass+148>: ld [ %l1 + 0x24 ], %g2
0xfea63cd8 <jni_FindClass+152>: btst %g2, %g3
0xfea63cdc <jni_FindClass+156>: be %icc, 0xfea63cf0 <jni_FindClass+176>
0xfea63ce0 <jni_FindClass+160>: sethi %hi(0x1c00), %g2
0xfea63ce4 <jni_FindClass+164>:
    call 0xfed5b3c0 <void JavaThread::check_safepoint_and_suspend_for_native_trans(JavaThread*)>
0xfea63ce8 <jni_FindClass+168>: mov %l1, %o0
0xfea63cec <jni_FindClass+172>: sethi %hi(0x1c00), %g2
(gdb) i reg l1
l1 0x21e8c0 2222272


JavaThread::_threadObj is 0xf5cafe80.

(gdb) x /x 0x21e8c0 + 224
0x21e9a0: 0xf5cafe80

Data for _threadObj (java.lang.Thread) is not set.

(gdb) x /8x 0xf5cafe80
0xf5cafe80: 0x00000001 0xf5cf5da0 0x00000000 0x00000000
0xf5cafe90: 0x00000000 0x00000000 0x00000000 0x00000000

Our initial thought for the above situation is
  java.lang.Thread has been allocated, but String of Thread.name
  is not.
Because the end of heap is 0xf5cb0000, java.lang.Thread can be allocated
to the limit.

We think the following scenario.

(1) A thread does AttachCurrentThread, but fails because of OOME.
    _thread_state of JavaThread which is created halfway is
    _thread_in_jvm. (Please see *1)
(2) The thread which is the same to (1) tries to do AttachCurrentThread.
    This trial succeeds apart from the heap status.(Please see *2)
    The _thread_state is _thread_in_vm, but should be _thread_in_native.
(3) Safepoint starts.
    VMThread examines the thread at (2).
    Because the status is _thread_in_vm, _call_back is set to
    _safepoint_state.
(4)Thread at (2) calls FindClass.
   transition_from_native is called and _thread_state changes to
  _thread_in_native_trans.
(5) Inconsistency status has been found in SafepointSynchronize::block.

(*1)
JavaCallWrapper::~JavaCallWrapper() {
...
  ThreadStateTransition::transition_from_java(_thread, _thread_in_vm);

(*2)
static jint attach_current_thread(JavaVM *vm, void **penv, void *_args, bool daemon) {
...
  Thread* t = ThreadLocalStorage::get_thread_slow();
  if (t != NULL) {
    // If the thread has been attacted this operation is a no-op
    *(JNIEnv**)penv = ((JavaThread*) t)->jni_environment();
    return JNI_OK;
  }


If DetachCurrentThread has not been done at (1), we think the above story
may occur.

We also investigate Tiger source code. Some new lines of code has been added
in Tiger.(if(attached_failed))

------ hotspot\src\share\vm\prims/jni.cpp -----
.....
  // Create Java level thread object and attach it to this thread
  bool attach_failed = false;
  {
    EXCEPTION_MARK;
    HandleMark hm(THREAD);
    Handle thread_group(THREAD, group);
    thread->allocate_threadObj(thread_group, thread_name, daemon, THREAD);
    if (HAS_PENDING_EXCEPTION) {
      CLEAR_PENDING_EXCEPTION;
      // cleanup outside the handle mark.
      attach_failed = true;
    }
  }

  if (attach_failed) {
    // Added missing cleanup
    thread->cleanup_failed_attach_current_thread();
    return JNI_ERR;
  }

-------

The similar logic should be needed in 1.4.2.

====== Customer Investigation end ========


CONFIGURATION :
JDK 1.4.2_05 Server VM
OS Solaris 9

REPRODUCE :
 (1) compile attached a.c and a.java.
 (2) Launch "java a"