EVALUATION
not reproducible on a single processor linux machine with kernel patch 2.4.7-10.
I am trying to get hold of a multiprocessor linux m/c with RHEL 3.0 installed.
###@###.### 2004-01-27
---------------------------------------------------
###@###.### 2004-02-12
I tested it on a machine ###@###.### provided with RHEL3.0 on it,
qt0.Ireland.Sun.COM. Stack size on this machine was set pretty high at 10m(10240k). With this size the test case failed after creating around 280 threads. That means threads have already taken up 2.73GB and an outofmemory error seems very likely. After I reduced the stack size to 1024k the probelm is not reproducible.
I have a suspicion, this bug was raised after testing on a machine which had ulimit -s set to a very high value.
I would like the originator of this bug to confirm if this was the case.
The test case is available at
/tmp/Threads6/Threads6 on qt0.Ireland.Sun.COM.
I added a line to Threads6.java to print Thread# in each iteration.
As it stands currently, it doesn't look like a bug.
Let me know after you test with a proper stack size.
---------------------------------------------------------------
Adjusting the stack size to 1024 does work on RHEL. However, should this be necessary?
I set the stacksize to 10240 on a RH 8.0 and RHAS 2.1 (multi-processor) and on both times the test (Threads6) passed.(200 threads created)
Details of 2.1 RHAS computer :
[root@xplg1 Threads6]# uname -a
Linux xplg1 2.4.9-e.3smp #1 SMP Fri May 3 16:48:54 EDT 2002 i686 unknown
[root@xplg1 Threads6]# more /etc/redhat-release
Red Hat Linux Advanced Server release 2.1AS (Pensacola)
[root@xplg1 Threads6]# ulimit -s
10240
[root@xplg1 Threads6]#
this still looks like a problem between RHAS3.0 and java.
###@###.### 2004-02-12
---------------------------------------
###@###.### 2004-02-13
Please set up a gdb & other trace tools like strace on qt0, so that I can debug this issue further. I could not fine them in /usr/bin.
Also, give me log in permissions on the machine where it succeeds with 10240k size.
--------------------------------------------------
###@###.### 2004-02-17
Setting the env variable LD_ASSUME_KERNEL to 2.4.9, makes the program run to completion without any problems. Since 2.4.20 kernel, NPTL support is provided.
Setting LD_ASSUME_KERNEL disables usage of NPTL and we don't see problem reproduced with LinuxThreads.
Running top showed that by the time the process crashed using NPTL, the stack+data size had grown to 1527M.
This looks like a problem due to NPTL usage on RHEL3.
This also probably explains why it's not reproduced on RH 8.0 and RHAS 2.1.
RH8 uses kernel 2.4.18 & RHAS 2.1 uses 2.4.9 on xplg1.ireland.
NPTL as far as I know is supported only for 1.4.2 and 1.4.1_03 (??).
Now, I am not sure if we want to implement NPTL support in 1.3.1_XX.
---------------------------------------------------------
|
Java