From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 25029 invoked by alias); 15 May 2009 20:23:56 -0000 Received: (qmail 25014 invoked by uid 22791); 15 May 2009 20:23:54 -0000 X-SWARE-Spam-Status: No, hits=-1.3 required=5.0 tests=AWL,BAYES_05 X-Spam-Check-By: sourceware.org Received: from mail.nanometrics.ca (HELO mail.nanometrics.ca) (206.191.47.130) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Fri, 15 May 2009 20:23:49 +0000 Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.nanometrics.ca (Postfix) with ESMTP id 510A5287586D; Fri, 15 May 2009 16:23:47 -0400 (EDT) Received: from mail.nanometrics.ca ([127.0.0.1]) by localhost (mail.nanometrics.ca [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k4mreIKKo6+j; Fri, 15 May 2009 16:23:42 -0400 (EDT) Received: from [10.11.2.17] (beng-pc.nanometrics.ca [10.11.2.17]) by mail.nanometrics.ca (Postfix) with ESMTP id E5E5C28756A9; Fri, 15 May 2009 16:23:42 -0400 (EDT) Message-ID: <4A0DCF4D.1030506@nanometrics.ca> Date: Fri, 15 May 2009 20:23:00 -0000 From: Ben Gardiner User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Andrew Haley CC: GCJ Subject: Re: libSegFault.so and gcj References: <4A0C38A1.4010300@nanometrics.ca> <4A0C40E7.6080907@redhat.com> In-Reply-To: <4A0C40E7.6080907@redhat.com> 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/msg00050.txt.bz2 Andrew Haley wrote: >> I reason from this that the segfaults are likely stack overflows. Could >> anyone confirm this? >> > That's quite possible. Do you not have a debugger? > > Clearly if it really is a stack overflow then you're not going to be > able to call the null pointer handler. There is a way around this, > though. If you use the -fstack-check option gcc generates a probe > at the start of every method that writes a zero some 12kbytes below > the stack pointer. This will give you enough stack space for the > catch_segv handler to run. David Daney wrote: > 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. Andrew and David, thank you for your insights and for the speed with which they were provided. About the debugger; I agree it would be the easiest way to figure out what's going on here. Since I don't know how to reproduce the problem I was hoping to get some information from our devices in the field if and when they die of a segmentation fault. Would it be possible -- and if so, are there any significant drawbacks -- to store the previous handler in INIT_SEGV and register it when catch_segv is entered, then re-register catch_segv on the way out? Would this allow the segv signal to be passed up to libSegFault.so's handler when it would have otherwise resulted in a recursive dead-end? ,Ben Gardiner