orig synopsis:  "segmentation fault of jdk 1.3.1-RC1 on linux"




segmentation fault

I've installed jdk 1.3.1 RC1 on SuSE Linux 7.1 (Kernel 2.2.18 or 2.4.0 - doesn't
matter) with XFree86 4.0.3

I've tried both rpm-packages and .tar file.

Afer installation a "./java -version" only produces the output "segmentation fault"


(remark: the jdk 1.3.1 beta-b15 is working fine)
(Review ID: 120614) 
======================================================================




cannot run it: it just crashes at any launch.
it's java1.3.1ea

Downloaded the generic shell installer for Linux.
Installed it ona Linux SuSE 7.1.
Running java shows segmentation fault (even java -version).
Running java -classic is ok.
(Review ID: 120635)
======================================================================




java -version creates the segmentation fault.

Linux phalanx 2.4.3 #2 Fri Mar 30 09:06:19 CEST 2001 i686 unknown

GNU C Library stable release version 2.2, by Roland McGrath et al.
Compiled by GNU CC version 2.95.2 19991024 (release).
Compiled on a Linux 2.4.0 system on 2001-01-19.
(Review ID: 120647)
======================================================================




Java(TM) 2 Runtime Environment, Standard Edition (build 1.3.1-rc1-b21)
Classic VM (build 1.3.1-rc1-b21, green threads, nojit)

Suse Linux 7.1 with glibc 2.2.2 KDE 2.2.1 Xfree 4.0.3 and Kernel 2.4.3

The - classic switch works, starting without switch generates an immediate
sigsegv

(Directly cut and paste from my console)
pet:/usr2/jdk1.3.1/bin # ./java -version
Segmentation fault
pet:/usr2/jdk1.3.1/bin # ./java -client -version
Segmentation fault
pet:/usr2/jdk1.3.1/bin # ./java -hotspot -version
Segmentation fault
pet:/usr2/jdk1.3.1/bin # ./java -server -version
Segmentation fault
pet:/usr2/jdk1.3.1/bin # ./java -classic -version
java version "1.3.1-rc1"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.3.1-rc1-b21)
Classic VM (build 1.3.1-rc1-b21, green threads, nojit)

The same problem occurs when i try to start netbeans qithout -classic 

I also got the message from the german java newsgroup that other people
have the same problem, they used a stock Suse Linux 7.1 with kernel 2.4.0
I'am using a self build kernel, not the one distributed with Suse.
I also made my glibc myself.

As a side note. I have no problem with any of: ibm jdk version, black
down versions or sun version with a a relase number lesser than 1.3.1
(Review ID: 120544)
======================================================================





java -version segmentation faults, however,
java -classic -version returns this:

java version "1.3.1-rc1"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.3.1-rc1-b21)
Classic VM (build 1.3.1-rc1-b21, green threads, nojit)

1. java -version (or any other commandline) for the -client, -server and
-hotspot JITs (-classic does not produce this bug)

2. none, java -version will do

3. none, the shell reports: Segmentation fault

4a. the last lines of a "DEBUG_PROG=strace" invocation are:

	16:28:44 open(".hotspotrc", O_RDONLY) = -1
                      ENOENT (No such file or directory)
	16:28:44 rt_sigaction(SIGSEGV, NULL, {SIG_DFL},8)  = 0
	16:28:44 rt_sigaction(SIGSEGV, {0x4002e8c0, ~[], SA_STACK|SA_RESTART|SA_SIGINFO|0x4000000}, {SIG_DFL}, 8) = 0
	16:28:44 rt_sigaction(SIGPIPE, NULL, {SIG_DFL}, 8) = 0
	16:28:44 rt_sigaction(SIGPIPE, {0x4002e8c0, ~[], SA_RESTART|SA_SIGINFO|0x4000000}, {SIG_DFL}, 8)    = 0
	16:28:44 rt_sigaction(SIGCHLD, NULL, {SIG_DFL}, 8) = 0
	16:28:44 rt_sigaction(SIGCHLD, {0x4002e8c0, ~[], SA_RESTART|SA_SIGINFO|SA_NOCLDSTOP|0x4000000}, {SIG_DFL}, 8) = 0
	16:28:44 rt_sigaction(SIGBUS, NULL, {SIG_DFL}, 8)                                                   = 0
	16:28:44 rt_sigaction(SIGBUS, {0x4002e8c0, ~[], SA_RESTART|SA_SIGINFO|0x4000000}, {SIG_DFL}, 8) = 0
	16:28:44 rt_sigaction(SIGILL, NULL, {SIG_DFL}, 8) = 0
	16:28:44 rt_sigaction(SIGILL, {0x4002e8c0, ~[], SA_RESTART|SA_SIGINFO|0x4000000}, {SIG_DFL}, 8)     = 0
	16:28:44 rt_sigaction(SIGFPE, NULL, {SIG_DFL}, 8) = 0
	16:28:44 rt_sigaction(SIGFPE, {0x4002e8c0, ~[], SA_RESTART|SA_SIGINFO|0x4000000}, {SIG_DFL}, 8)  = 0
	16:28:44 rt_sigaction(SIGUSR2, {0x4002e8c0, [], SA_RESTART|SA_SIGINFO|0x4000000}, NULL, 8) = 0
	16:28:44 getrlimit(RLIMIT_NOFILE, {rlim_cur=1024, rlim_max=1024}) = 0
	16:28:44 setrlimit(RLIMIT_NOFILE, {rlim_cur=1024, rlim_max=1024}) = 0
	16:28:44 brk(0x804f000) = 0x804f000
	16:28:44 getpid() = 21089
	16:28:44 old_mmap(0x4000f000, 8192, PROT_READ|PROT_WRITE|PROT_EXEC, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x4000f000
	16:28:44 mprotect(0x4000f000, 8192, PROT_NONE) = 0
	16:28:44 old_mmap(0x40005000, 40960, PROT_READ|PROT_WRITE|PROT_EXEC, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x40005000
	16:28:44 --- SIGSEGV (Segmentation fault) ---
	16:28:44 --- SIGSEGV (Segmentation fault) ---
	16:28:44 +++ killed by SIGSEGV +++

4b. the last lines of a "DEBUG_PROG=ltrace" invocation are:

	fgets("-client\n", 4095, 0x0804c960)               = 0xbfffadac
	strlen(0xbfffadac, 0, 0, 0, 0)                           = 8
	strdup("-client")                                            = 0x0804cad0
	fgets("-hotspot\n", 4095, 0x0804c960)            = 0xbfffadac
	strlen(0xbfffadac, 0, 0, 0, 0)                           = 9
	strdup("-hotspot")                                         = 0x0804cae0
	fgets("-server\n", 4095, 0x0804c960)             = 0xbfffadac
	strlen(0xbfffadac, 0, 0, 0, 0)                           = 8
	strdup("-server")                                           = 0x0804caf0
	fgets("-classic\n", 4095, 0x0804c960)            = 0xbfffadac
	strlen(0xbfffadac, 0, 0, 0, 0)                           = 9
	strdup("-classic")                                         = 0x0804cb00
	fgets("-classic", 4095, 0x0804c960)              = NULL
	fclose(0x0804c960)                                      = 0
	sprintf("/usr/lib/jdk1.3.1-sun/jre/lib/i3"..., "%s/lib/%s/%s/libjvm.so","/usr/lib/jdk1.3.1-sun/jre", "i386", "client") = 51
	stat(0xbfffcde0, 0xbfffcd4c, 0x4000ce1e, 0x40016c54, 0x40555540) = 0
	dlopen("/usr/lib/jdk1.3.1-sun/jre/lib/i3"..., 258) = 0x40017798
	dlsym(0x40017798, "JNI_CreateJavaVM")             = 0x401957f4
	dlsym(0x40017798, "JNI_GetDefaultJavaVMInitArgs") = 0x401958c8
	getenv("CLASSPATH")                               =  ".:/usr/gen/java/jsdk2.0/lib/jsdk"...
	strlen(0xbffff484, 7, 0xbfffee14, 0x08048f56, 0xbffff484) = 133
	malloc(173)                                       = 0x0804cb10
	sprintf("-Djava.class.path=.:/usr/gen/jav"..., "-Djava.class.path=%s", ".:/usr/gen/java/jsdk2.0/lib/jsdk"...) = 151
	malloc(32)                                                  = 0x0804cbc8
	memset(0xbfffcd98, '\000', 16)                    = 0xbfffcd98
	strcmp("File", "Memory")                             = -7
	strcmp("File", "Library")                               = -6
	strcmp("File", "System")                             = -13
	strcmp("File", "Thread")                              = -14
	strcmp("File", "File")                                   = 0
	strcmp("Library", "Memory")                       = -1
	strcmp("Library", "Library")                         = 0
	strcmp("System", "Memory")                      = 6
	strcmp("System", "Library")                       = 7
	strcmp("System", "System")                      = 0
	--- SIGSEGV (Segmentation fault) ---
	--- SIGSEGV (Segmentation fault) ---
	+++ killed by SIGSEGV +++




5. additional info:

5a. running as: root

5b. output of: uname -a:
	Linux clausi 2.4.0-4GB #1 Mon Jan 22 16:42:16 GMT 2001 i686 unknown

5c. distribution: SuSE 7.1

5d. ulimit -a:
	core file size (blocks)     0
	data seg size (kbytes)      unlimited
	file size (blocks)          unlimited
	max locked memory (kbytes)  unlimited
	max memory size (kbytes)    unlimited
	open files                  1024
	pipe size (512 bytes)       8
	stack size (kbytes)         unlimited
	cpu time (seconds)          unlimited
	max user processes          8190
	virtual memory (kbytes)     unlimited

5e. output of: DEBUG_PROG=ldd java
        libpthread.so.0 => /lib/libpthread.so.0 (0x40025000)
        libhpi.so => /usr/lib/jdk1.3.1-sun/jre/lib/i386/native_threads/libhpi.so
(0x4003b000)
        libjvm.so => /usr/lib/jdk1.3.1-sun/jre/lib/i386/client/libjvm.so
(0x40045000)
        libdl.so.2 => /lib/libdl.so.2 (0x40429000)
        libc.so.6 => /lib/libc.so.6 (0x4042c000)
        libnsl.so.1 => /lib/libnsl.so.1 (0x4053f000)
        libm.so.6 => /lib/libm.so.6 (0x40556000)
        libstdc++-libc6.1-1.so.2 => /usr/lib/libstdc++-libc6.1-1.so.2
(0x40574000)
        /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000)
(Review ID: 120766)
======================================================================




java version "1.3.1-rc1"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.3.1-rc1-b21)
Classic VM (build 1.3.1-rc1-b21, green threads, nojit)


Starting the java executable aborts immediately with a segfault. The classic
VM works, though.

Witnessed under glibc 2.2 on a SuSE Linux system. Segfaults under kernel
2.2.18 and 2.4.3.
(Review ID: 120769)
======================================================================

change the default stack size to any number but "unlimited". 
e.g. "ulimit -s 8192"

 xxxxx@xxxxx  2001-04-16

--------------------------------

"ulimit -s 8192" is not enough (see evaluation). It is *highly* recommended
to limit default thread stack size to under 2M!!

limit -s 2048

 xxxxx@xxxxx  2001-07-11

The default stack size on SuSE 7.1 is "unlimited". getrlimit() would return
2G for stack size and cause VM to put guard pages at very low virtual memory
address space, which caused the crash.

It could happen on Redhat 7.1 too if user changed the default stack size from
8M to "unlimited".

User can easily get around the problem by setting limitted stack size. We can
fix it by limiting the maximum stack size.

 xxxxx@xxxxx  2001-04-16

----------------------------

fixed by limiting maximum stack size to 8M

 xxxxx@xxxxx  2001-04-20

----------------------------

As it turns out, limiting the stack size to 8M is not enough. There is
a bug/limitation in the pthread library that it cannot handle correctly
when thread stack size is larger than 6M (look at the initialization of
__pthread_initial_thread_bos in pthread.c, it is blindly initialized
to <top address> - 6M), any stack size larger than this will cause SEGV
in the pthread signal wrapper whenever there is a signal that requires
alternate signal stack to handle.

In case there are other code in the pthread library (or VM) that assumes 
the old 2M-fixed thread stack, it is *highly* recommended to limit the max 
thread stack size to under 2M. 

On bash, do the following: "limit -s 2048"; 
or on tcsh, "limit stacksize 2048".

This bug will affect systems using glibc-2.2.x that is not compiled with
2.4 kernel (w/o "--enable-kernel=2.4.0"), but will not affect glibc-2.2.x 
when it's compiled with the flag (e.g., Redhat 7.1).

Please also see bug 4466587.

 xxxxx@xxxxx  2001-07-11

I still see this problem even with the workaround on 1.3.1-
b24 (the FCS 1.3.1) on Suse 7.1 under 2.4 and 2.2.18 
kernels.

I also see this problem under SuSe 7.1 under the 2.4 kernel.
 I do not see the problem running java -version, but I do
see the problem only when running programs with more than
one thread.

After much fiddling around, I got the 1.3.1 JVM to work 
with a stack size of 2000.  8192 does not work on my 
machine; however, I have not had any problems since I 
added a line to /usr/bin/java to set ulimit -s 2000 before 
doing anything else.

We are having exactly the same problem (SuSe 7.1, Kernel 
2.4). The workaround has no affect. What now?

Probably the same problem on Debian running 2.4.5 kernel with 1.3.1. However, it did not crash on startup. It only segfaulted with one application that was using Apache's Xerces XML parser. Ulimit is set to 8192 by default. This does NOT help. Setting it to 4096 fixed the problem (as it seems).

Running Forte Teamware from the prompt started to segfault 
on me after upgrading to Mandrake8. Starting the same tool 
from within the IDE didn't crash.

Setting the ulimit -s to 2000 stops the crashing.
Setting the ulimit -s to 8000 (default in Mandrake) does 
not solve this issue for me.

I tried ulimit -s 2048 on SuSE 7.1 (Kernel 2.2.4) with VM 
1.3.1-b24. This workaround seems to solve the problem; I do 
no more have Segmentation Faults.

The suggested fix "limit stacksize 2048" worked
for me under SuSE-7.2.

ulimit -s 2048 works for me also under SuSE 7.2, kernel 2.4.4, Java 1.3.1-b24. Thanks to those who've 
mentioned that here.

I also see this problem under SuSe 7.2 under the 2.4 kernel.
 I do not see the problem running java -version, but I do
see the problem only when running programs with more than
one thread.
I tried ulimit -s 2048 on SuSE 7.2 (Kernel 2.2.4) with VM 
1.3.1-b24. This workaround seems to solve the problem; I do 
no more have Segmentation Faults.
Thanks to those who've mentioned that here.

"ulimit -s 2048" worked for me on RedHat 7.1, HotSpot Client
VM 1.3.1-b24.
My default stack size of 8192 causes the seg fault (which
only happens
on more complex programs, like running an Ant build).

It would be good if the J2SE SDK's INSTALLATION doc for
Linux mentioned that the stack size problem (and ulimit
workaround) apply to RedHat 7.1,
and not just 7.0.

To add a kernel note to the above comment: I have kernel
2.4.2-2, and glibc-2.2.2-10, and as I mentioned, I have the
segfault
problem with stack size 8192 but not with stack size 2048. 
Is the
2001-07-11 Evaluation note above correct, then, in saying
that the
bug will not affect glibc-2.2.x compiled with
--enable-kernel=2.4.0?

Is this a difference between minor versions of the 2.4
kernel?  Is it
possible to be running the 2.4 kernel *without* glibc-2.2
being compiled
against 2.4?  How would I check how my glibc-2.2 was
compiled?

The 'ulimit -s' work-around was not effective for me either.
I tried a number of values. I'm using libc-2.2.3 and Debian
w/2.2.17.

I am running Mandrake 8.0 out of the box and had the same
problem.  "ulimit -s 2048" solved it.

I tried the ulimit -s 2048 workaround with Mandrake 8.0,
glibc-2.2.4-6mdk and kernel 2.2.17-21mdk and this DOES NOT
WORK.  

It works once, then I get segmentation faults over and over,
then I type ulimit -s 2048 and it works, once, then not,
then some other times it doesn't work at all, even after the
ulimit.

Does not work for me.