JDK-5052974 : Hprof crashes on encountering ThreadGroup with null name
  • Type: Bug
  • Component: tools
  • Sub-Component: hprof
  • Affected Version: 1.4.2
  • Priority: P4
  • Status: Resolved
  • Resolution: Fixed
  • OS: generic
  • CPU: generic
  • Submitted: 2004-05-26
  • Updated: 2004-06-03
  • Resolved: 2004-06-03
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
5.0 b55Fixed
Related Reports
Relates :  
Description

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

Comments
CONVERTED DATA BugTraq+ Release Management Values COMMIT TO FIX: tiger-rc FIXED IN: tiger-rc INTEGRATED IN: tiger-b55 tiger-rc
01-09-2004

SUGGESTED FIX For hprof in v1.5: (cd /net/cruella.sfbay/export/home4/ws/kto_j2se/src/share/demo/jvmti/hprof && sccs diffs -w -C -r1.45 hprof_io.c ) ------- hprof_io.c ------- *** /tmp/sccs._KaOCq Wed May 26 11:06:26 2004 --- hprof_io.c Wed May 26 11:06:01 2004 *************** *** 1778,1784 **** write_printf("THREAD START " "(obj=%x, id = %d, name=\"%s\", group=\"%s\")\n", thread_obj_id, thread_serial_num, ! thread_name, thread_group_name); } } --- 1778,1785 ---- write_printf("THREAD START " "(obj=%x, id = %d, name=\"%s\", group=\"%s\")\n", thread_obj_id, thread_serial_num, ! (thread_name==NULL?"":thread_name), ! (thread_group_name==NULL?"":thread_group_name)); } }
01-09-2004

EVALUATION First, it appears to me that nothing disallows the thread group name being null, as much as I find that strange to allow. The Java implementation doesn't like a Thread name being null: Exception in thread "main" java.lang.NullPointerException at java.lang.Thread.init(Thread.java:289) at java.lang.Thread.<init>(Thread.java:375) at Test.main(Test.java:9) but it allows a ThreadGroup name being null. I actually see nothing in the Java specification that disallows either name being null, but maybe I missed it. I'll search to see if there is a Java spec related bug or issue on this. Second, it's happening in JVMTI and JVMPI, for JVMTI the trace is: [11] VMError::report_and_die(0x256cc, 0x25400, 0x26400, 0xff1638b0, 0xff08465c, 0x0), at 0xfe58be7c [12] report_assertion_failure(0xfea6c5d6, 0x211, 0xfea6c62c, 0x24144, 0x11a8698, 0xff314d0c), at 0xfdf4ca70 [13] java_lang_ThreadGroup::name(0x0, 0xb3798, 0x10c0f38, 0xff271200, 0x23c00, 0xff0f50a8), at 0xfe0341ac [14] JvmtiEnv::GetThreadGroupInfo(0x3ea78, 0xfefefc00, 0xf8d7fb04, 0x1f3898, 0x24400, 0xff146888), at 0xfe3285d0 [15] jvmti_GetThreadGroupInfo(0x3ea84, 0x58868, 0xf8d7fb04, 0x1f3898, 0xf8d7fc54, 0xff16357c), at 0xfe257be4 [16] getThreadGroupInfo(thread_group = 0x58868, info = 0xf8d7fb04), line 1283 in "hprof_util.c" [17] event_thread_start(env = 0x1f396c, thread = 0x57f64), line 389 in "hprof_event.c" [18] cbThreadStart(jvmti = 0x3ea84, env = 0x1f396c, thread = 0x57f64), line 1351 in "hprof_init.c" [19] JvmtiExport::post_thread_start(0x23000, 0x1f3898, 0xead0, 0xff162418, 0x1, 0xff0f50a8), at 0xfe34c0f4 [20] JavaThread::run(0x1f3898, 0x1ec, 0x7f9389, 0x7f9c7b, 0xff0f50a8, 0x23800), at 0xfe513008 [21] _start(0x1f3898, 0x26fdc, 0xcd390c, 0x1f3f58, 0x26c00, 0xff0f50a8), at 0xfe421908 I will dup a separate bug on jvmti/jvmpi on this 5053405. I've kept this bug for the hprof change. Third, even if this is fixed, v1.5 hprof will croak if it doesn't allow for null thread and thread group names. I will fix hprof in v1.5 for this. Regardless of the decision to change JVMTI (5053405), the hprof in v1.5 should never crash on this. The older JVMPI based hprof (e.g. v1.4) seemed to allow null for these names and should not need hprof changes, but you would need JVMPI changed, i.e. you need bug 5053405 fixed for JVMPI. So for a complete fix in v1.5, you will also need 5053405 fixed for JVMTI. -kto ###@###.### 2004-05-26
26-05-2004