From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 12070 invoked by alias); 14 May 2009 16:10:11 -0000 Received: (qmail 12061 invoked by uid 22791); 14 May 2009 16:10:09 -0000 X-SWARE-Spam-Status: No, hits=-1.2 required=5.0 tests=AWL,BAYES_50 X-Spam-Check-By: sourceware.org Received: from mail3.caviumnetworks.com (HELO mail3.caviumnetworks.com) (12.108.191.235) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Thu, 14 May 2009 16:10:04 +0000 Received: from exch4.caveonetworks.com (Not Verified[192.168.16.23]) by mail3.caviumnetworks.com with MailMarshal (v6,2,2,3503) id ; Thu, 14 May 2009 12:09:35 -0400 Received: from exch4.caveonetworks.com ([192.168.16.23]) by exch4.caveonetworks.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 14 May 2009 09:08:46 -0700 Received: from dd1.caveonetworks.com ([64.169.86.201]) by exch4.caveonetworks.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 14 May 2009 09:08:46 -0700 Message-ID: <4A0C420E.7080708@caviumnetworks.com> Date: Thu, 14 May 2009 16:10:00 -0000 From: David Daney User-Agent: Thunderbird 2.0.0.21 (X11/20090320) MIME-Version: 1.0 To: Ben Gardiner CC: GCJ Subject: Re: libSegFault.so and gcj References: <4A0C38A1.4010300@nanometrics.ca> In-Reply-To: <4A0C38A1.4010300@nanometrics.ca> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-IsSubscribed: yes Mailing-List: contact java-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: java-owner@gcc.gnu.org X-SW-Source: 2009-05/txt/msg00048.txt.bz2 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