From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 30301 invoked by alias); 1 Dec 2009 17:24:42 -0000 Received: (qmail 30284 invoked by uid 22791); 1 Dec 2009 17:24:42 -0000 X-SWARE-Spam-Status: No, hits=-2.5 required=5.0 tests=AWL,BAYES_00,SPF_HELO_PASS,SPF_PASS,WEIRD_PORT X-Spam-Check-By: sourceware.org Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Tue, 01 Dec 2009 17:24:36 +0000 Received: from int-mx08.intmail.prod.int.phx2.redhat.com (int-mx08.intmail.prod.int.phx2.redhat.com [10.5.11.21]) by mx1.redhat.com (8.13.8/8.13.8) with ESMTP id nB1HOVuE031061 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 1 Dec 2009 12:24:31 -0500 Received: from zebedee.pink (ovpn01.gateway.prod.ext.phx2.redhat.com [10.5.9.1]) by int-mx08.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id nB1HOThm028463; Tue, 1 Dec 2009 12:24:30 -0500 Message-ID: <4B15514D.2010708@redhat.com> Date: Tue, 01 Dec 2009 17:24:00 -0000 From: Andrew Haley User-Agent: Thunderbird 2.0.0.23 (X11/20090825) MIME-Version: 1.0 To: Jack Howarth CC: borlum , java@gcc.gnu.org Subject: Re: [patch] Fix oddity in personality routine References: <20091127215118.GA6568@bromo.med.uc.edu> <4B10FECE.8010600@redhat.com> <20091129174835.GB13043@bromo.med.uc.edu> <4B12B6D9.5050008@redhat.com> <20091129184804.GA13502@bromo.med.uc.edu> <4B1399CD.9070401@redhat.com> <20091130160125.GA25831@bromo.med.uc.edu> <4B13EDB1.9090102@redhat.com> <20091201050157.GA1933@bromo.med.uc.edu> <4B14E200.8030007@redhat.com> <20091201170403.GA8810@bromo.med.uc.edu> In-Reply-To: <20091201170403.GA8810@bromo.med.uc.edu> Content-Type: text/plain; charset=ISO-8859-1 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-12/txt/msg00003.txt.bz2 Jack Howarth wrote: > On Tue, Dec 01, 2009 at 09:29:36AM +0000, Andrew Haley wrote: >> Jack Howarth wrote: >> >>> (gdb) >>> 54 (*real_main) (args); >>> (gdb) >>> >>> Program received signal EXC_BAD_ACCESS, Could not access memory. >>> Reason: KERN_PROTECTION_FAILURE at address: 0x0000000103f05db0 >>> 0x0000000103f05db0 in ?? () at RowSetEvent.java:51 >>> 51 RowSetEvent.java: No such file or directory. >>> in RowSetEvent.java >>> (gdb) >>> >>> A backtrace only shows... >>> >>> (gdb) bt >>> #0 0x0000000103f05db0 in ?? () at RowSetEvent.java:51 >>> #1 0x00000001000485be in gnu::java::lang::MainThread::call_main (this=0x104875dc0) at ../../../gcc-4.5-20091128/libjava/gnu/java/lang/natMainThread.cc:54 >>> Previous frame inner to this frame (gdb could not unwind past this frame) >>> >>> Let me know if you have any suggestions for debugging this further. >> Disassemble the first 10 or so instructions at the instruction where the >> EXC_BAD_ACCESS occurs. I think this is a libffi bug. >> >> Andrew. > > Andrew, > So just to clarify, for the instance of... > > ------------------- > > (gdb) > 0x00000001004168df in _ZN4java4lang7reflect8Modifier8isPublicEJbi (mod=9) at Modifier.java:258 > 258 return (mod & PUBLIC) != 0; > (gdb) > gnu::java::lang::MainThread::call_main (this=0x104875dc0) at ../../../gcc-4.5-20091128/libjava/gnu/java/lang/natMainThread.cc:46 > 46 msg = "`main' must be public"; > (gdb) > 45 else if (! ::java::lang::reflect::Modifier::isPublic(meth->accflags)) > (gdb) > 54 (*real_main) (args); > (gdb) > > Program received signal EXC_BAD_ACCESS, Could not access memory. > Reason: KERN_PROTECTION_FAILURE at address: 0x0000000103f05db0 > 0x0000000103f05db0 in ?? () at RowSetEvent.java:51 > 51 RowSetEvent.java: No such file or directory. > in RowSetEvent.java > (gdb) > > A backtrace only shows... > > (gdb) bt > #0 0x0000000103f05db0 in ?? () at RowSetEvent.java:51 > #1 0x00000001000485be in gnu::java::lang::MainThread::call_main (this=0x104875dc0) at ../../../gcc-4.5-20091128/libjava/gnu/java/lang/natMainThread.cc:54 > Previous frame inner to this frame (gdb could not unwind past this frame) > > ----------------- > > I want to disassemble from 0x00000001000485be, right? 0x0000000103f05db0, where the fault happens. I think it's a libffi stub, and I think its page permissions are not correctly set. But let's see. What I would do is, at > 54 (*real_main) (args); disassemble the call instruction, it's probably call ($rax) or somesuch. look in $rax with p $rax and disassemble from the address that's in there. Andrew.