From: Jack Howarth <howarth@bromo.med.uc.edu>
To: Andrew Haley <aph@redhat.com>
Cc: borlum <thomas@borlum.dk>, java@gcc.gnu.org
Subject: Re: [patch] Fix oddity in personality routine
Date: Thu, 03 Dec 2009 14:03:00 -0000 [thread overview]
Message-ID: <20091203140334.GA8556@bromo.med.uc.edu> (raw)
In-Reply-To: <4B17921A.8090403@redhat.com>
On Thu, Dec 03, 2009 at 10:25:30AM +0000, Andrew Haley wrote:
> 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.
Andrew,
This sounds like the patch that Andreas proposed in...
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41991#c3
which didn't solve the problem on my MacPro or MacBook Pro
under darwin9 or darwin10. He also ran into the issue again
later...
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41991#c17
Do you think that -Wl,-allow_stack_execute needs to be passed
even more widely than on just ecjx_LDFLAGS? Any suggestions as
to where I should be passing it? Perhaps on something like
LIBJAVA_LDFLAGS_NOUNDEF at the toplevel of libjava? Or should
we even be building libffi and boehm-gc with that as well?
Jack
next prev parent reply other threads:[~2009-12-03 14:03 UTC|newest]
Thread overview: 61+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-11-13 17:49 Eric Botcazou
2009-11-13 17:57 ` Andrew Haley
2009-11-13 18:36 ` Jack Howarth
2009-11-13 18:39 ` Andrew Haley
2009-11-13 19:18 ` Jack Howarth
2009-11-15 23:02 ` Bryce McKinlay
2009-11-16 14:22 ` Jack Howarth
2009-11-16 15:12 ` Jack Howarth
2009-11-16 15:17 ` Andrew Haley
2009-11-16 15:34 ` Jack Howarth
2009-11-16 16:59 ` Andrew Haley
2009-11-16 18:07 ` Jack Howarth
2009-11-16 19:10 ` Andrew Haley
2009-11-16 19:48 ` Jack Howarth
2009-11-17 0:48 ` Jack Howarth
2009-11-17 10:59 ` Andrew Haley
2009-11-17 14:05 ` Jack Howarth
2009-11-17 14:56 ` Andrew Haley
2009-11-17 16:18 ` Jack Howarth
2009-11-17 16:22 ` Andrew Haley
2009-11-17 17:07 ` Jack Howarth
2009-11-17 17:14 ` Andrew Haley
2009-11-17 17:38 ` Jack Howarth
2009-11-27 10:37 ` borlum
2009-11-27 10:40 ` Andrew Haley
2009-11-27 10:52 ` borlum
2009-11-27 14:20 ` Bryce McKinlay
2009-11-27 16:29 ` Jack Howarth
2009-11-27 21:51 ` Jack Howarth
2009-11-28 10:43 ` Andrew Haley
2009-11-29 17:48 ` Jack Howarth
2009-11-29 18:01 ` Andrew Haley
2009-11-29 18:48 ` Jack Howarth
2009-11-30 10:09 ` Andrew Haley
2009-11-30 16:01 ` Jack Howarth
2009-11-30 16:07 ` Andrew Haley
2009-12-01 5:02 ` Jack Howarth
2009-12-01 9:30 ` Andrew Haley
2009-12-01 17:04 ` Jack Howarth
2009-12-01 17:24 ` Andrew Haley
2009-12-01 23:29 ` Jack Howarth
2009-12-02 9:34 ` Andrew Haley
2009-12-03 1:08 ` Jack Howarth
2009-12-03 10:26 ` Andrew Haley
2009-12-03 14:03 ` Jack Howarth [this message]
2009-12-03 14:10 ` Andrew Haley
2009-12-03 19:18 ` Boehm, Hans
2009-12-03 21:25 ` Andrew Haley
2009-12-04 3:01 ` Jack Howarth
2009-12-04 9:45 ` Andrew Haley
2009-12-04 4:12 ` Jack Howarth
2009-12-04 9:44 ` Andrew Haley
2009-12-04 14:51 ` Jack Howarth
2009-12-04 14:59 ` Andrew Haley
2009-12-04 15:23 ` Jack Howarth
2009-12-04 15:48 ` Andrew Haley
2009-12-04 15:57 ` Bryce McKinlay
2009-12-05 4:37 ` Jack Howarth
2009-12-05 6:54 ` Jack Howarth
2009-12-04 15:59 ` Jack Howarth
2009-12-04 16:06 ` Andrew Haley
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20091203140334.GA8556@bromo.med.uc.edu \
--to=howarth@bromo.med.uc.edu \
--cc=aph@redhat.com \
--cc=java@gcc.gnu.org \
--cc=thomas@borlum.dk \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).