JDK-6576701 : Thread.getName does not handle null name
  • Type: Bug
  • Component: core-svc
  • Sub-Component: java.lang.management
  • Affected Version: 6
  • Priority: P4
  • Status: Closed
  • Resolution: Duplicate
  • OS: linux
  • CPU: x86
  • Submitted: 2007-07-03
  • Updated: 2023-12-14
  • Resolved: 2011-03-23
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
tbdResolved
Related Reports
Duplicate :  
JDK-6508261 - NPE occurs in ThreadMXBean.getThreadInfo
Relates :  
JDK-6412693 - JNI attached threads can be seen to be partially constructed
Relates :  
JDK-6404306 - IllegalArgumentException:Invalid thread ID occurs in 6.0b76
Description
FULL PRODUCT VERSION :
java version "1.6.0"
Java(TM) SE Runtime Environment (build 1.6.0-b105)
Java HotSpot(TM) Server VM (build 1.6.0-b105, mixed mode)


ADDITIONAL OS VERSION INFORMATION :
Redhat, kernel 2.4.21-27.0.1.ELsmp

A DESCRIPTION OF THE PROBLEM :
When java.lang.management.ThreadMXBean.dumpAllThreads() is called, it can call Thread.getName() when the "name" field is null. This causes a NullPointerException, and the dumpAllThreads() call fails. It has only happened once at webserver startup when the machine is very busy and lots of threads are being initialized, but it killed the thread since the exception was unexpected.

STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
Not sure how to reproduce it reliably, but it would probably involve creating threads while calling dumpAllThreads() repeatedly while the machine is very heavily loaded.

EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
Eventually, a thread with a null name would be caught.

ERROR MESSAGES/STACK TRACES THAT OCCUR :
Exception in thread "PeriodicThreadDumper" java.lang.NullPointerException
      at java.lang.String.<init>(String.java:176)
      at java.lang.String.valueOf(String.java:2841)
      at java.lang.Thread.getName(Thread.java:1061)
      at java.lang.management.ThreadInfo.initialize(ThreadInfo.java:205)
      at java.lang.management.ThreadInfo.<init>(ThreadInfo.java:177)
      at sun.management.ThreadImpl.dumpThreads0(Native Method)
      at sun.management.ThreadImpl.dumpAllThreads(ThreadImpl.java:374)
      at jlib.ThreadDumper16.captureThreadData(ThreadDumper16.java:56)
      at jlib.PeriodicThreadDumper.run(PeriodicThreadDumper.java:51)
      at java.lang.Thread.run(Thread.java:619)


REPRODUCIBILITY :
This bug can be reproduced rarely.

CUSTOMER SUBMITTED WORKAROUND :
Catch the exception and call the method again (either dumpAllThreads or getName as the case may be). In my case, I'll retry calling dumpAllThreads
Comments
EVALUATION This could be similar to the problem reported in 6508261 that a NPE is thrown when accessing an attaching thread that is not fully initialized. The ThreadInfo initialization should handle the case where Thread.getName() returns null.
16-07-2007
EVALUATION Hmmm. If I write the obvious test case creating a thread with a null name, an NPE is thrown at constuction: public class Test { public static void main(String ... args) { Thread t = new Thread((String)null); t.getName(); } } $ java Test Exception in thread "main" java.lang.NullPointerException at java.lang.Thread.init(Thread.java:367) at java.lang.Thread.<init>(Thread.java:437) at Test.main(Test.java:3) $ java -version java version "1.7.0-ea" Java(TM) SE Runtime Environment (build 1.7.0-ea-b14) Java HotSpot(TM) Tiered VM (build 1.7.0-ea-b14, mixed mode) Presumably the management system has caught the NPE and continued with its processing. I've filed a new bug 6576763 to requests that the Thread constructors document their historical behaviour of throwing NPE for null name. I don't believe that the management system will have a fully initialized thread if the NPE is thrown. Routing to the management team to determine if a thread has been incorrectly constructed or to modify their code to be tolerant of NPE from their Thread.getName() invocations.
03-07-2007