Re: [patch] Fix oddity in personality routine

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.