[patch] Fix oddity in personality routine

Tue Dec 1 17:24:00 GMT 2009

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.