Intel Xeon + Linux + IBM sdk 1.3.1 - getting Segmentation fault

[Alex Hunsley]

I've installed the IBM java sdk 1.3.1 SR5 (exact download was "IBM SDK
for 32-bit xSeries (Intel compatible)") on an intel Xeon machine running
Redhat 9.0. When I run "javac" I get "Segmentation fault" (without any
core dump file produced), but "java" itself seems to work ok on a simple
text class.
Can anyone advise on if the above setup has any inherent problems that
I've missed or why this might be happening?
Also, what is the advised setup in terms on environment vars? IBMs site
seemed to be lacking in such derails, instead referring you to sun's site.

The current env. vars that are relevant to this situation are set as:


export JAVA_HOME=/opt/IBMJava2-131
export PATH=$JAVA_HOME/bin:$JAVA_HOME/jre/bin:$PATH
export CLASSPATH=
(i.e. classpath set to nothing)


some additional info in case it helps:



[root@jura java_5]# uname -a
Linux jura 2.4.20-8smp #1 SMP Thu Mar 13 17:45:54 EST 2003 i686 i686
i386 GNU/Linux

[root@jura java_5]# more /proc/cpuinfo
processor : 0
vendor_id : GenuineIntel
cpu family : 15
model : 2
model name : Intel(R) Xeon(TM) CPU 2.80GHz
stepping : 7
cpu MHz : 2784.692
cache size : 512 KB
physical id : 0
siblings : 2
fdiv_bug : no
hlt_bug : no
f00f_bug : no
coma_bug : no
fpu : yes
fpu_exception : yes
cpuid level : 2
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 sep mtrr pge mca
cmov pat p
se36 clflush dts acpi mmx fxsr sse sse2 ss ht tm
bogomips : 5557.45



thanks
alex

 

[Ben_]

Try disabling HyperThreading.

 

[Alex Hunsley]

Try disabling HyperThreading.

At what level/how?


thanks,
alex

 

[Ben_]

It's a feature of the Xeon Processors
(http://www.intel.com/products/ht/hyperthreading_more.htm) and you can
disable it at the BIOS level (if supported, otherwise it is probably
disabled). Maybe it won't solve your problem, but I know of people getting
core dumps when HT is enabled.

 

[Alex Hunsley]

It's a feature of the Xeon Processors
(http://www.intel.com/products/ht/hyperthreading_more.htm) and you can
disable it at the BIOS level (if supported, otherwise it is probably
disabled). Maybe it won't solve your problem, but I know of people getting
core dumps when HT is enabled.

Thanks for that.
In the meantime I have tried installing the same IBM sdk on another
machine, a celeron, with exactly the same seg fault when I run "javac".
(The cpuinfo for the celeron:

$ more /proc/cpuinfo
processor : 0
vendor_id : GenuineIntel
cpu family : 6
model : 8
model name : Celeron (Coppermine)
stepping : 10
cpu MHz : 897.284
cache size : 128 KB
fdiv_bug : no
hlt_bug : no
f00f_bug : no
coma_bug : no
fpu : yes
fpu_exception : yes
cpuid level : 2
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 sep mtrr pge mca
cmov pat p
se36 mmx fxsr sse
bogomips : 1789.13

)

cheers
alex

 

[Ben_]

OK, then forget about HT.

You may want to turn off JIT compiler (-Djava.compiler=NONE on the command
line starting your app). This also has proven to be the cause of problems.
If it solves it, then you may want to install the latest revision of IBM
JVM.

 

[Alex Hunsley]

It's a feature of the Xeon Processors
(http://www.intel.com/products/ht/hyperthreading_more.htm) and you can
disable it at the BIOS level (if supported, otherwise it is probably
disabled). Maybe it won't solve your problem, but I know of people
getting
core dumps when HT is enabled.

Thanks for that.
In the meantime I have tried installing the same IBM sdk on another
machine, a celeron, with exactly the same seg fault when I run "javac".
(The cpuinfo for the celeron:
[snip]

hmm, the installed executables don't even look like executables:

$ gdb javac_g
GNU gdb Red Hat Linux (5.3post-0.20021129.18rh)
[snip]
executable format: File format not recognized

So presumably I have the wrong architecture release or something?

alex

 

[Ben_]

I'm not Linux-enabled so I can't help much with this...

 

[Gordon Beaton]

hmm, the installed executables don't even look like executables:

$ gdb javac_g
GNU gdb Red Hat Linux (5.3post-0.20021129.18rh)
[snip]
executable format: File format not recognized

So presumably I have the wrong architecture release or something?

"file" will identify the file formats.

/gordon

 

[Alex Hunsley]

hmm, the installed executables don't even look like executables:

$ gdb javac_g
GNU gdb Red Hat Linux (5.3post-0.20021129.18rh)
[snip]
executable format: File format not recognized

So presumably I have the wrong architecture release or something?

"file" will identify the file formats.

/gordon

Doh! my bad! the java and javac etc. under bin/ are shell scripts, which
then run natives exes in /bin/exe...
still no idea why I get Segmentation fault though.
alex

 

[Christophe Vanfleteren]

hmm, the installed executables don't even look like executables:

$ gdb javac_g
GNU gdb Red Hat Linux (5.3post-0.20021129.18rh)
[snip]
executable format: File format not recognized

So presumably I have the wrong architecture release or something?

"file" will identify the file formats.

/gordon

Doh! my bad! the java and javac etc. under bin/ are shell scripts, which
then run natives exes in /bin/exe...
still no idea why I get Segmentation fault though.
alex

It could have something to do with the fact that Redhat ships with NPTL, a
new threading library. I once had javac segfaulting when I compiled glibc
with NPTL support.

from the Redhat 9.0 release notes:

o Red Hat Linux 9 includes the Native POSIX Thread Library
(NPTL), a new implementation of POSIX threads for Linux. This library
provides performance improvements and increased scalability for i686
or better processors.

This thread library is designed to be binary compatible with the old
LinuxThreads implementation; however, applications that rely on the
places where the LinuxThreads implementation deviates from the POSIX
standard will need to be fixed. Notable differences include:
[....]
Applications that are known to have problems using NPTL include:

- Sun JRE prior to version 1.4.1

- IBM JRE

 

[Alex Hunsley]

Alex Hunsley wrote:

Gordon Beaton wrote:

On Mon, 03 Nov 2003 14:14:00 +0000, Alex Hunsley wrote:


hmm, the installed executables don't even look like executables:

$ gdb javac_g
GNU gdb Red Hat Linux (5.3post-0.20021129.18rh)
[snip]
executable format: File format not recognized

So presumably I have the wrong architecture release or something?


"file" will identify the file formats.

/gordon

Doh! my bad! the java and javac etc. under bin/ are shell scripts, which
then run natives exes in /bin/exe...
still no idea why I get Segmentation fault though.
alex

It could have something to do with the fact that Redhat ships with NPTL, a
new threading library. I once had javac segfaulting when I compiled glibc
with NPTL support.

from the Redhat 9.0 release notes:

o Red Hat Linux 9 includes the Native POSIX Thread Library
(NPTL), a new implementation of POSIX threads for Linux. This library
provides performance improvements and increased scalability for i686
or better processors.

This thread library is designed to be binary compatible with the old
LinuxThreads implementation; however, applications that rely on the
places where the LinuxThreads implementation deviates from the POSIX
standard will need to be fixed. Notable differences include:
[....]
Applications that are known to have problems using NPTL include:

- Sun JRE prior to version 1.4.1

- IBM JRE

Aha, thankyou for that info, that is very helpful.
alex

 

[Roedy Green]

When I run "javac" I get "Segmentation fault" (without any
core dump file produced), but "java" itself seems to work ok on a simple
text class.

see http://mindprod.com/jgloss/javac.exe for some of the option
switches. Perhaps a different combination will work. Perhaps it is
just javac.exe by itself that fails. Give it something to compile.

I am not familiar with Linux, but is there something you can do to run
the program in a debugging mode that will give you more of a clue?

Are Xeons just expensive Pentiums or do they have their own native
instruction set? If so, perhaps there is a switch to get it to use
the pentium instruction set.

 

[Roedy Green]

In the meantime I have tried installing the same IBM sdk on another
machine, a celeron, with exactly the same seg fault when I run "javac".
(The cpuinfo for the celeron:

You might want to get a fresh copy of the JDK. See
http://mindprod.com/jgloss/jdk.html

 

[=?iso-8859-1?Q?Nils_O=2E_Sel=E5sdal?=]

I've installed the IBM java sdk 1.3.1 SR5 (exact download was "IBM SDK
for 32-bit xSeries (Intel compatible)") on an intel Xeon machine running
Redhat 9.0. When I run "javac" I get "Segmentation fault" (without any
core dump file produced), but "java" itself seems to work ok on a simple
text class.
Can anyone advise on if the above setup has any inherent problems that
I've missed or why this might be happening?
Also, what is the advised setup in terms on environment vars? IBMs site
seemed to be lacking in such derails, instead referring you to sun's site.

The current env. vars that are relevant to this situation are set as:


export JAVA_HOME=/opt/IBMJava2-131
export PATH=$JAVA_HOME/bin:$JAVA_HOME/jre/bin:$PATH
export CLASSPATH=
(i.e. classpath set to nothing)


some additional info in case it helps:

Redhat now ships the NPTL , which means it now has a pthreads conformant
threading library. The old java verson were built to use the LinuxThread
library, and did several ugly thinks to work around LinuxThreads.
The newer versions (1.4.x iirc) should handle NTPL, the old one does not.
Force the java vm to use LinuxThreads:

LD_ASSUME_KERNEL=2.4.18 java whatever

or e.g
LD_ASSUME_KERNEL=2.4.18 javac whatever.java

 

[Alex Hunsley]

Redhat now ships the NPTL , which means it now has a pthreads conformant
threading library. The old java verson were built to use the LinuxThread
library, and did several ugly thinks to work around LinuxThreads.
The newer versions (1.4.x iirc) should handle NTPL, the old one does not.
Force the java vm to use LinuxThreads:

LD_ASSUME_KERNEL=2.4.18 java whatever

or e.g
LD_ASSUME_KERNEL=2.4.18 javac whatever.java

I presume you mean set the above value and then call javac?
I've tried this and I still get a segmentation fault...

alex

 

[Alex Gibson]

see http://mindprod.com/jgloss/javac.exe for some of the option
switches. Perhaps a different combination will work. Perhaps it is
just javac.exe by itself that fails. Give it something to compile.

I am not familiar with Linux, but is there something you can do to run
the program in a debugging mode that will give you more of a clue?

Are Xeons just expensive Pentiums or do they have their own native
instruction set? If so, perhaps there is a switch to get it to use
the pentium instruction set.

smp capable p4's with extra cache

 

[tims]

I presume you mean set the above value and then call javac?
I've tried this and I still get a segmentation fault...

alex

I got it to work by setting the Kernel version back further:

LD_ASSUME_KERNEL=2.2.5 java -version

This command runs fine on Red Hat Linux 9. It used to seg fault
before. Give it a shot.

later,

tims