From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 10595 invoked by alias); 3 Dec 2009 10:26:18 -0000 Received: (qmail 10556 invoked by uid 22791); 3 Dec 2009 10:26:16 -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; Thu, 03 Dec 2009 10:25:41 +0000 Received: from int-mx01.intmail.prod.int.phx2.redhat.com (int-mx01.intmail.prod.int.phx2.redhat.com [10.5.11.11]) by mx1.redhat.com (8.13.8/8.13.8) with ESMTP id nB3APb08019313 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 3 Dec 2009 05:25:37 -0500 Received: from zebedee.pink (ovpn01.gateway.prod.ext.phx2.redhat.com [10.5.9.1]) by int-mx01.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id nB3APUgR003897; Thu, 3 Dec 2009 05:25:34 -0500 Message-ID: <4B17921A.8090403@redhat.com> Date: Thu, 03 Dec 2009 10:26: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: <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> <4B15514D.2010708@redhat.com> <20091201232939.GA20242@bromo.med.uc.edu> <4B1634A9.3000106@redhat.com> <20091203010828.GA684@bromo.med.uc.edu> In-Reply-To: <20091203010828.GA684@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/msg00012.txt.bz2 Jack Howarth wrote: > On Wed, Dec 02, 2009 at 09:34:33AM +0000, Andrew Haley wrote: >> Jack Howarth wrote: >>> On Tue, Dec 01, 2009 at 05:24:29PM +0000, Andrew Haley wrote: >>>> 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. >>> Andrew, >>> I can't disassemble 0x0000000103f05db0... >>> >>> (gdb) disassemble 0x0000000103f05db0 >>> No function contains specified address. >> x/10i 0x0000000103f05db0 >> >> Andrew. > > Andrew, > Okay, I see... > > gdb /sw/lib/gcc4.5/libexec/gcc/x86_64-apple-darwin9.8.0/4.5.0/ecj1 > ... > gdb) break ../../../gcc-4.5-20091128/libjava/gnu/java/lang/natMainThread.cc:46 > Breakpoint 1 at 0x20c49ba4b0a5ab: file ../../../gcc-4.5-20091128/libjava/gnu/java/lang/natMainThread.cc, line 46. > (gdb) r testme.java -fbootclasspath=/sw/share/java/ecj/ecj.jar:./:/sw/lib/gcc4.5/share/java/libgcj-4.5.0.jar -fsource=1.5 -ftarget=1.5 -fzip-dependency /var/folders/1C/1CdoNxmNFHyOIjNBLNuJh++++TM/-Tmp-//ccQOWl1c.zip -fzip-target /var/folders/1C/1CdoNxmNFHyOIjNBLNuJh++++TM/-Tmp-//cc4p4DHj.jar > Starting program: /sw/lib/gcc4.5/libexec/gcc/x86_64-apple-darwin9.8.0/4.5.0/ecj1 testme.java -fbootclasspath=/sw/share/java/ecj/ecj.jar:./:/sw/lib/gcc4.5/share/java/libgcj-4.5.0.jar -fsource=1.5 -ftarget=1.5 -fzip-dependency /var/folders/1C/1CdoNxmNFHyOIjNBLNuJh++++TM/-Tmp-//ccQOWl1c.zip -fzip-target /var/folders/1C/1CdoNxmNFHyOIjNBLNuJh++++TM/-Tmp-//cc4p4DHj.jar > warning: posix_spawn failed, trying execvp, error: 86 > Reading symbols for shared libraries +++++.. done > Breakpoint 1 at 0x1000485ab: file ../../../gcc-4.5-20091128/libjava/gnu/java/lang/natMainThread.cc, line 46. > > Breakpoint 1, 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) s > Current language: auto; currently c++ > 45 else if (! ::java::lang::reflect::Modifier::isPublic(meth->accflags)) > (gdb) s > 54 (*real_main) (args); > (gdb) x/10i 0x0000000103f05db0 > 0x103f05db0: mov $0x1009814e8,%r11 > 0x103f05dba: mov $0x103f05db0,%r10 > 0x103f05dc4: clc > 0x103f05dc5: rex.WB jmpq *%r11 > 0x103f05dc8: add %bl,-0x10(%rsi) > 0x103f05dcb: add (%rcx),%eax > 0x103f05dcd: add %al,(%rax) > 0x103f05dcf: add %ah,%al > 0x103f05dd1: (bad) > 0x103f05dd2: cwtl > (gdb) bt > #0 gnu::java::lang::MainThread::call_main (this=0x104875dc0) at ../../../gcc-4.5-20091128/libjava/gnu/java/lang/natMainThread.cc:54 > #1 0x0000000104875dc0 in ?? () at ClassHelper.java:106 > #2 0x0000000104875f00 in ?? () at ClassHelper.java:106 > #3 0x000000010493e980 in ?? () at ClassHelper.java:106 > #4 0x00000001000b1b74 in _ZN3gnu4java4lang10MainThread3runEJvv (this=0x104875dc0) at MainThread.java:106 > Previous frame inner to this frame (gdb could not unwind past this frame) > (gdb) p $rax > $1 = 1 > > (gdb) s > > Program received signal EXC_BAD_ACCESS, Could not access memory. > Reason: KERN_PROTECTION_FAILURE at address: 0x0000000103f05db0 > 0x0000000103f05db0 in ?? () at ClassHelper.java:106 > 106 ClassHelper.java: No such file or directory. > in ClassHelper.java > > What do you make of the bad assembly at 0x103f05dd1? There is no bad assembly: there's a jump at 0x103f05dc5. I know what's going on. The OS forbids execution of memory in the heap. But, there is an extra flag, -Wl,-allow_stack_execute, that allows this permission. This is a misnamed flag, since we never execute code on the stack. I think it's really controlling heap execution, not stack execution. We need to pass this flag everywhere, whenever a program is compiled by gcj. Andrew.