JDK-6325849 : Java Thread Dump shows the same 'nid' for all threads
  • Type: Bug
  • Component: hotspot
  • Sub-Component: runtime
  • Affected Version: 1.4.2
  • Priority: P4
  • Status: Closed
  • Resolution: Fixed
  • OS: linux
  • CPU: x86
  • Submitted: 2005-09-19
  • Updated: 2012-10-08
  • Resolved: 2006-02-21
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
1.4.2_12 b01Fixed
Description
FULL PRODUCT VERSION :
build 1.4.2_09-b05

ADDITIONAL OS VERSION INFORMATION :
Linux localhost 2.4.21-27.0.2.EL #1 Wed Jan 12 23:46:37 EST 2005 i686 i686 i386 GNU/Linux

A DESCRIPTION OF THE PROBLEM :
All the threads in the thread dump (obtained from kill -3) showed the same nid.

I suspect it is the use of getpid() function in the JVM.

Before kernel 2.4, getpid() returns the thread's PID. In Linux, each thread has a different PID.

In 2.4, Linux tried to conform to POSIX and return the process PID with getpid(). Thus all the threads ends up with the same lwp_id, i.e. the process PID.



STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
type 'kill -3 <PID>'

EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
Each thread has a unique 'nid'
ACTUAL -
All threads share the same 'nid' - the process PID

ERROR MESSAGES/STACK TRACES THAT OCCUR :
none. It would be impossible to map the 'top' and 'ps' output to the thread dump. In cases when one thread goes into high CPU usage, it would be impossible to know which one, since there is no way to map 'top' and 'ps' output to the thread dump.

REPRODUCIBILITY :
This bug can be reproduced always.

Comments
WORK AROUND Setting the environment variable LD_ASSUME_KERNEL=2.4.1 eliminates the problem. Setting LD_ASSUME_KERNEL tells the system to use the old LinuxThreads implementation instead of the newer NPTL. As a result, the nid's in the dump now map correctly to the process IDs in the output of ps. I tested the workaround on the following RedHat system: Linux blacksheep 2.4.21-4.ELsmp #17 SMP Wed Sep 28 15:30:47 MSD 2005 i686 i686 i386 GNU/Linux More info: The Native POSIX Threading Library replaces LinuxThreads and NGPT in the 2.5 and later kernels.Some Linux vendors, such as later versions of Red Hat Linux, have backported NPTL to earlier kernels and have even made the threading environment for specific processes selectable through an environment variable (LD_ASSUME_KERNEL). On systems that support this feature, the variable is set via a command such as the following: # export LD_ASSUME_KERNEL=2.4.1 This is a clever way to enable some existing applications that rely on LinuxThreads to continue to work in an NPTL environment, but is a short-term solution. To make the most of the design and performance benefits provided by NPTL, you should update the code for any existing applications that use threading.
14-10-2005

EVALUATION This issue has been addressed in 1.5.0.. Request for getting this issue back ported to 1.4.2_X where X is the next release..
20-09-2005