###@###.### 2004-03-01

VTest failed on AMD SLES8 and Itanium RedHat AS3.0 with tiger build 40.

Java version:
Java HotSpot(TM) 64-Bit Server VM (build 1.5.0-beta2-b40, mixed mode)

Test machine1: jtg-amd3 ( 4 way AMD )
Linux jtg-amd3 2.4.21-127-smp #1 SMP

Test machine2: jtg-it7 ( 2 way Itanium 2)
Linux jtg-it7.sfbay.sun.com 2.4.18-e.12smp #1 SMP


Steve G. and Paul H. looked at the processes.
"We segv'd in this code:

void JavaThread::thread_main_inner() {
  assert(JavaThread::current() == this, "sanity check");
  assert(this->threadObj() != NULL, "just checking");

  // Execute thread entry point. If this thread is being asked to restart,
  // or has been stopped before starting, do not reexecute entry point.
  // Note: Due to JVM_StopThread we can have pending exceptions already!
  if (!this->has_pending_exception() &&
!java_lang_Thread::is_stillborn(this->threadObj())) {

We we actually in java_lang_Thread::is_stillborn when we segv. It looked like
this->threadObj() had returned NULL (i.e. javaThread not fully initialized)
and since that code doesn't protect itself from NULL (and it shouldn't) it
segv."

"Anyway this look again like for some reason the Java object representing
the thread failed to allocate. This is on the java heap and we expect that either it will allocate or we'll throw an out-of-memory exception. Very strange.
I seem to recall some changes in the jdk w.r.t ThreadGroups. Since that code
comes into play here I wonder if it is somehow related."