Red Hat Bugzilla – Bug 69198
IBM 1.3.1 JDK does not run on AS/7.2 SMP
Last modified: 2016-11-24 10:20:29 EST
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.0) Gecko/20020606
Description of problem:
The IBM 1.3.1 JDK that ships with Advanced Server freezes on 7.2 and Advanced
Server SMP machines. It runs fine on 7.2 and AS single-processor machines.
Additionally, the JDK runs fine on 7.3 SMP and single-processor machines.
I have a dual-cpu box with 7.2. This box has glibc-2.2.4-24 on it and also the
When I run a java process on the box, the java process freezes.
I found a discussion at
that suggested trying to set the LD_ASSUME_KERNEL=2.2.5 environment variable to
address this issue.
When I set this parameter, the java process will run and not freeze. However,
the JDK performance is extremely slow when I set this parameter. Additionally,
I will see sporadic defunct Java processes remaining after I stop running Java.
I do not see this behaviour with the 1.3.1 JDK on 7.3 SMP.
One other thing that I have tried is to replace the 2.4.9-31smp kernel on the
7.2 box with a 2.4.18-5smp kernel from a 7.3 box. With this kernel, Java will
run without the LD_ASSUMER_KERNEL=2.2.5 parameter set. However, it is still slow.
So, there seems to be some glibc bug in 7.2/AS that prevents the JDK from
running on smp boxes. The 2.4.9-based SMP kernels with this glibc cause Java to
freeze unless the LD_ASSUME_KERNEL=2.2.5 parameter is set. The 2.4.18-based
kernels somehow do not freeze with this glibc, but performance is still
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. run a Java program with the IBM 1.3.1 JDK
Actual Results: The Java process freezes
Expected Results: It should run
Created attachment 66025 [details]
This software will reproduce the JDK error using ant
The Read Me for the IBM Java SDK 1.3.1 states firmly that the environment
variable LD_ASSUME_KERNEL must be set for SMP operation. I have included the
relevant section below. This explains the "freeze" behaviour described in this
The technical justification for this restriction is as follows:-
On Intel, there is a kernel bug such that registers can be corrupted when we
switch context on an SMP. This is fixed in the 2.4.10 kernel. This affects the
JIT such that we have to use an alternate method to store a pointer to our
ExecEnv but, this alternate method doesnt work if Linux is using floating
stacks. Thus, if you are on an IA32 SMP with floating stacks (eg RedHat) with a
2.4.0-2.4.9 kernel you have to turn off floating stacks using an environment
The extract from the Read Me is:-
Working with floating stacks
Certain Linux distributions - Red Hat, for example - have enabled a GLIBC
feature called 'floating stacks'. Because of Linux kernel limitations, the JVM
will not run on SMP hardware with floating stacks enabled if the kernel level
is less than 2.4.10. In this environment, floating stacks must be disabled
before the JVM, or any application that starts the JVM, is started. On Red Hat,
you disable floating stacks by exporting an environment variable, thus:
On a non-floating stack Linux system, regardless of what is set for -Xss, a
minimum native stack size of 256KB for each thread is provided. On a floating
stack Linux system, the -Xss values are honored. Thus, if you are migrating
from a non-floating stack Linux system, you must ensure that any -Xss values
are large enough and are not relying on a minimum of 256KB.
This readme is inaccurate, since it was not 2.4.10 where the LDT SMP problems
were fixed, but 2.4.8 AFAIK.
This has not been updated in over a year. Is this still a problem since the most
recent Quartly Update (QU2)?
Someone (Jakub?) fixed the glibc bug and it was pushed out at least six months
ago. We're not seeing this bug on our AS2.1 SMP machines any more.
As per comment #5, closing as resolved in CURRENTRELEASE.