Name: rmT116609 Date: 05/25/2004


FULL PRODUCT VERSION :
java version "1.5.0-beta"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0-b
Java HotSpot(TM) Client VM (build 1.5.0-beta-b32c, mixed mode)

java version "1.4.2_04"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2_04-b05)
Java HotSpot(TM) Client VM (build 1.4.2_04-b05, mixed mode)

ADDITIONAL OS VERSION INFORMATION :
Microsoft Windows 2000 [Version 5.00.2195]
Linux 2.4.20

A DESCRIPTION OF THE PROBLEM :
When running under hprof (including 1.5, 1.4, and 1.3 implementations), starting a thread attached to a ThreadPool with a name of null will crash with an Access Violation/SIGSEV


STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
Compile the class provided below and execute with 'java -Xrunhprof Test'

EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
Silent completion
ACTUAL -
VM crash. Error message described below.

ERROR MESSAGES/STACK TRACES THAT OCCUR :
On Win2K it appears as:
# EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x6d69e857, pid=784, tid=1984
#
# Java VM: Java HotSpot(TM) Client VM (1.5.0-beta-b32c mixed mode)
# Problematic frame:
# V [jvm.dll+0x7e857]

On Linux it appears as:
Unexpected Signal : 11 occurred at PC=0x403A7EA5
Function=name__21java_lang_ThreadGroupP7oopDesc+0x25
Library=/opt/sun-jdk-1.4.1.02/jre/lib/i386/client/libjvm.so

REPRODUCIBILITY :
This bug can be reproduced always.

---------- BEGIN SOURCE ----------
<code>
public class Test extends ThreadGroup {

        public Test() {
                super(null);
        }

        public static void main(String[] ARGS) {
                Test t = new Test();
                Thread th = new Thread(t, "Test thread");
                th.start();
        }
}
</code>
---------- END SOURCE ----------

CUSTOMER SUBMITTED WORKAROUND :
Do not instantiate ThreadGroups with null name.
(Incident Review ID: 275077)
======================================================================

A more accurate testcase:

class MyThread extends Thread {
    public MyThread(ThreadGroup g, String name) {
        super(g,name);
    }
    public void run() {
        try {
            synchronized( this ) {
                wait();
            }
        } catch ( InterruptedException i ) {
        }
    }
}
public class Test {
    public static void main(String[] ARGS) {
        Thread th = new MyThread(new ThreadGroup((String)null), "tname");
        th.start();
        System.out.println("ThreadGroup=" + th.getThreadGroup().toString());
        synchronized( th ) {
            th.notify();
        }
    }
}

It appears that the original testcase could allow the child thread to complete
before the main thread, causing a different situation inside hprof when
it requests information about threads. The above is more reliable.


###@###.### 2004-05-26