J2SDK 1.3.1 on Linux Segmentation Fault

["Douglas E. Hornig" <do...@hornig.net>]

A while ago I posted a question about a segmentation fault error I was getting with Tomcat.  The machine is SuSE Linux 7.1 and the application was fine with J2SDK 1.3 but when I switched to J2SDK 1.3.1 it aborted with a segmentation fault.  It turns out that it was aborting in the call to new DOMParser() in Xerces so it's not a Tomcat problem per se, but I still think it's worth mentioning what I found.

I have discovered that this is a documented problem (Sun Java bug database ID 4466587).  The problem appears when an exception is thrown inside a deeply recursive call and seems to be related to glibc-2.2-x.  I gather that glibc-2.1-x enforced a 2M stack size limit but glibc-2.2-x does not, but it can only handle larger stacks if it's compiled with --enable-kernel=2.4.0 .  The workaround is to set 'ulimit -s 2048' in your bash shell or 'limit stacksize 2048' in tcsh before starting the VM.  I have not tried recompiling glibc.

Re: J2SDK 1.3.1 on Linux Segmentation Fault

[Tim O'Neil <ti...@xythos.com>]

At 05:55 AM 7/3/2001, you wrote:
>A while ago I posted a question about a segmentation fault error I was 
>getting with Tomcat.  The machine is SuSE Linux 7.1 and the application 
>was fine with J2SDK 1.3 but when I switched to J2SDK 1.3.1 it aborted with 
>a segmentation fault.  It turns out that it was aborting in the call to 
>new DOMParser() in Xerces so it's not a Tomcat problem per se, but I still 
>think it's worth mentioning what I found.
>
>I have discovered that this is a documented problem (Sun Java bug database 
>ID 4466587).  The problem appears when an exception is thrown inside a 
>deeply recursive call and seems to be related to glibc-2.2-x.  I gather 
>that glibc-2.1-x enforced a 2M stack size limit but glibc-2.2-x does not, 
>but it can only handle larger stacks if it's compiled with 
>--enable-kernel=2.4.0 .  The workaround is to set 'ulimit -s 2048' in your 
>bash shell or 'limit stacksize 2048' in tcsh before starting the VM.  I 
>have not tried recompiling glibc.

To add more possibly useless comments to this it seems like a good
idea generally to up the limits in the descriptor table for most of
the params in a production system. I myself have encountered a number
of problems that have been solved by increasing the number of file
descriptors for example. A lot of unices ship with a default value
of 64 for this; way to low for a production system. I typically edit
(or create) startup scripts that use the root shell (sh) to kick off
processes by adding ulmit command the increase the handles and descriptors
to various production levels that seem to be useful, it also helps to
know and be comfortable with setting the heap size settings in the jvm,
although I see in my 1.3.1 copy running on 2K the -mx and -sx options
seem to be missing...