[patch] Fix oddity in personality routine

Wed Dec 2 09:34:00 GMT 2009

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.