Re: [patch] Fix oddity in personality routine

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.