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.
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.