Re: libSegFault.so and gcj

[David Daney <ddaney@caviumnetworks.com>]

Ben Gardiner wrote:
> Hello all,
> 
> We are running a gcj-compiled application on an embedded platform
> (MPC852T). For reference our versions are gcc-4.0.1, glibc-2.3.3 and
> linux-2.4.24 -- I know these versions are ancient, but please don't stop
> reading here.
> 
> We sometimes encounter segfaults in our application; that is to say that
> it will terminate with 'Segmentation fault' on the console and return
> 139. These occur rather infrequently, and we have yet to find a reliable
> way to reproduce them. To make things more difficult, we do not have
> room for core dumps on our filesystem.
> 
> I thought that we could get the some information about these segfaults
> by using the preload library libSegFault.so; I tested it and integrated
> it with our init scripts and let it loose into our releases hoping that
> a backtrace or two would come back to me. None did; there was no output
> produced by libSegFault.so at all.
> 
> I think that since gcj registers its own segfault handler which
> translates segv signals into NullPointerExceptions,
> 

That's right.

Usually if you die with a SIGSEGV, it is due to stack overflow.
Probably for one reason or another you are getting a fault during the
NullPointerException processing which causes the signal handler to be
reentered recursively.  This goes on until the stack overflows and the
kernel then kills the process.  If you could attach a debugger to the
process, that might shed some light on exactly what is happening.
Assuming that it is not normal for your application to take
NullPointerExceptions it shouldn't be too tedious.

David Daney