This is the mail archive of the
java@gcc.gnu.org
mailing list for the Java project.
Re: [patch] Fix oddity in personality routine
- From: Andrew Haley <aph at redhat dot com>
- To: Jack Howarth <howarth at bromo dot med dot uc dot edu>
- Cc: borlum <thomas at borlum dot dk>, java at gcc dot gnu dot org
- Date: Tue, 01 Dec 2009 17:24:29 +0000
- 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>
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.