Re: [patch] Fix oddity in personality routine

Jack Howarth <[email protected]>
Newsgroups gmane.comp.gcc.java.devel
Message-ID <[email protected]>
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.

Disassembling 0x00000001000485be shows...

(gdb) disassemble 0x00000001000485be
Dump of assembler code for function _ZN3gnu4java4lang10MainThread9call_mainEJvv:
0x00000001000484f0 <_ZN3gnu4java4lang10MainThread9call_mainEJvv+0>:	mov    %rbx,-0x18(%rsp)
0x00000001000484f5 <_ZN3gnu4java4lang10MainThread9call_mainEJvv+5>:	mov    %rdi,%rbx
0x00000001000484f8 <_ZN3gnu4java4lang10MainThread9call_mainEJvv+8>:	lea    0x94f508(%rip),%rdi        # 0x100997a07 <dyld_stub_write+10609>
0x00000001000484ff <_ZN3gnu4java4lang10MainThread9call_mainEJvv+15>:	mov    %rbp,-0x10(%rsp)
0x0000000100048504 <_ZN3gnu4java4lang10MainThread9call_mainEJvv+20>:	mov    %r12,-0x8(%rsp)
0x0000000100048509 <_ZN3gnu4java4lang10MainThread9call_mainEJvv+25>:	mov    $0x16,%esi
0x000000010004850e <_ZN3gnu4java4lang10MainThread9call_mainEJvv+30>:	sub    $0x18,%rsp
0x0000000100048512 <_ZN3gnu4java4lang10MainThread9call_mainEJvv+34>:	callq  0x100005a50 <_Z17_Jv_makeUtf8ConstPKci>
0x0000000100048517 <_ZN3gnu4java4lang10MainThread9call_mainEJvv+39>:	lea    0x94f500(%rip),%rdi        # 0x100997a1e <dyld_stub_write+10632>
0x000000010004851e <_ZN3gnu4java4lang10MainThread9call_mainEJvv+46>:	mov    $0x4,%esi
0x0000000100048523 <_ZN3gnu4java4lang10MainThread9call_mainEJvv+51>:	mov    %rax,%r12
0x0000000100048526 <_ZN3gnu4java4lang10MainThread9call_mainEJvv+54>:	callq  0x100005a50 <_Z17_Jv_makeUtf8ConstPKci>
0x000000010004852b <_ZN3gnu4java4lang10MainThread9call_mainEJvv+59>:	mov    0x80(%rbx),%rdi
0x0000000100048532 <_ZN3gnu4java4lang10MainThread9call_mainEJvv+66>:	mov    $0x3,%esi
0x0000000100048537 <_ZN3gnu4java4lang10MainThread9call_mainEJvv+71>:	mov    %rax,%rbp
0x000000010004853a <_ZN3gnu4java4lang10MainThread9call_mainEJvv+74>:	callq  0x100016830 <_ZN10_Jv_Linker14wait_for_stateEPN4java4lang5ClassEi>
0x000000010004853f <_ZN3gnu4java4lang10MainThread9call_mainEJvv+79>:	mov    0x80(%rbx),%rdi
0x0000000100048546 <_ZN3gnu4java4lang10MainThread9call_mainEJvv+86>:	xor    %ecx,%ecx
0x0000000100048548 <_ZN3gnu4java4lang10MainThread9call_mainEJvv+88>:	mov    %rbp,%rsi
0x000000010004854b <_ZN3gnu4java4lang10MainThread9call_mainEJvv+91>:	mov    %r12,%rdx
0x000000010004854e <_ZN3gnu4java4lang10MainThread9call_mainEJvv+94>:	callq  0x100051b10 <_Z24_Jv_LookupDeclaredMethodPN4java4lang5ClassEP13_Jv_Utf8ConstS4_PS2_>
0x0000000100048553 <_ZN3gnu4java4lang10MainThread9call_mainEJvv+99>:	test   %rax,%rax
0x0000000100048556 <_ZN3gnu4java4lang10MainThread9call_mainEJvv+102>:	mov    %rax,%rbp
0x0000000100048559 <_ZN3gnu4java4lang10MainThread9call_mainEJvv+105>:	je     0x1000485f0 <_ZN3gnu4java4lang10MainThread9call_mainEJvv+256>
0x000000010004855f <_ZN3gnu4java4lang10MainThread9call_mainEJvv+111>:	movzwl 0x10(%rax),%edi
0x0000000100048563 <_ZN3gnu4java4lang10MainThread9call_mainEJvv+115>:	callq  0x1004168b0 <_ZN4java4lang7reflect8Modifier8isStaticEJbi>
0x0000000100048568 <_ZN3gnu4java4lang10MainThread9call_mainEJvv+120>:	test   %al,%al
0x000000010004856a <_ZN3gnu4java4lang10MainThread9call_mainEJvv+122>:	lea    0x94f46a(%rip),%rdx        # 0x1009979db <dyld_stub_write+10565>
0x0000000100048571 <_ZN3gnu4java4lang10MainThread9call_mainEJvv+129>:	jne    0x1000485a0 <_ZN3gnu4java4lang10MainThread9call_mainEJvv+176>
0x0000000100048573 <_ZN3gnu4java4lang10MainThread9call_mainEJvv+131>:	mov    0x1329a96(%rip),%rax        # 0x101372010 <ffi_type_longdouble+48>
0x000000010004857a <_ZN3gnu4java4lang10MainThread9call_mainEJvv+138>:	lea    0x94f4a2(%rip),%rsi        # 0x100997a23 <dyld_stub_write+10637>
0x0000000100048581 <_ZN3gnu4java4lang10MainThread9call_mainEJvv+145>:	mov    (%rax),%rdi
0x0000000100048584 <_ZN3gnu4java4lang10MainThread9call_mainEJvv+148>:	xor    %eax,%eax
0x0000000100048586 <_ZN3gnu4java4lang10MainThread9call_mainEJvv+150>:	callq  0x100994d4e <dyld_stub_fprintf>
0x000000010004858b <_ZN3gnu4java4lang10MainThread9call_mainEJvv+155>:	mov    $0x1,%edi
0x0000000100048590 <_ZN3gnu4java4lang10MainThread9call_mainEJvv+160>:	callq  0x100994d1e <dyld_stub_exit>
0x0000000100048595 <_ZN3gnu4java4lang10MainThread9call_mainEJvv+165>:	nopl   0x0(%rax,%rax,1)
0x000000010004859a <_ZN3gnu4java4lang10MainThread9call_mainEJvv+170>:	nopw   0x0(%rax,%rax,1)
0x00000001000485a0 <_ZN3gnu4java4lang10MainThread9call_mainEJvv+176>:	movzwl 0x10(%rbp),%edi
0x00000001000485a4 <_ZN3gnu4java4lang10MainThread9call_mainEJvv+180>:	callq  0x1004168d0 <_ZN4java4lang7reflect8Modifier8isPublicEJbi>
0x00000001000485a9 <_ZN3gnu4java4lang10MainThread9call_mainEJvv+185>:	test   %al,%al
0x00000001000485ab <_ZN3gnu4java4lang10MainThread9call_mainEJvv+187>:	lea    0x94f43f(%rip),%rdx        # 0x1009979f1 <dyld_stub_write+10587>
0x00000001000485b2 <_ZN3gnu4java4lang10MainThread9call_mainEJvv+194>:	je     0x100048573 <_ZN3gnu4java4lang10MainThread9call_mainEJvv+131>
0x00000001000485b4 <_ZN3gnu4java4lang10MainThread9call_mainEJvv+196>:	mov    0x90(%rbx),%rdi
0x00000001000485bb <_ZN3gnu4java4lang10MainThread9call_mainEJvv+203>:	callq  *0x18(%rbp)
0x00000001000485be <_ZN3gnu4java4lang10MainThread9call_mainEJvv+206>:	callq  0x100062450 <_Z14_Jv_ThreadWaitv>
0x00000001000485c3 <_ZN3gnu4java4lang10MainThread9call_mainEJvv+211>:	lea    0x1629dde(%rip),%rax        # 0x1016723a8 <_ZN4java4lang11ThreadGroup22had_uncaught_exceptionE>
0x00000001000485ca <_ZN3gnu4java4lang10MainThread9call_mainEJvv+218>:	mov    (%rsp),%rbx
0x00000001000485ce <_ZN3gnu4java4lang10MainThread9call_mainEJvv+222>:	mov    0x8(%rsp),%rbp
0x00000001000485d3 <_ZN3gnu4java4lang10MainThread9call_mainEJvv+227>:	mov    0x10(%rsp),%r12
0x00000001000485d8 <_ZN3gnu4java4lang10MainThread9call_mainEJvv+232>:	movzbl (%rax),%edi
0x00000001000485db <_ZN3gnu4java4lang10MainThread9call_mainEJvv+235>:	add    $0x18,%rsp
0x00000001000485df <_ZN3gnu4java4lang10MainThread9call_mainEJvv+239>:	jmpq   0x100409600 <_ZN4java4lang7Runtime20exitNoChecksAccessorEJvi>
0x00000001000485e4 <_ZN3gnu4java4lang10MainThread9call_mainEJvv+244>:	nopw   0x0(%rax,%rax,1)
0x00000001000485ea <_ZN3gnu4java4lang10MainThread9call_mainEJvv+250>:	nopw   0x0(%rax,%rax,1)
0x00000001000485f0 <_ZN3gnu4java4lang10MainThread9call_mainEJvv+256>:	lea    0x94f3c1(%rip),%rdx        # 0x1009979b8 <dyld_stub_write+10530>
0x00000001000485f7 <_ZN3gnu4java4lang10MainThread9call_mainEJvv+263>:	jmpq   0x100048573 <_ZN3gnu4java4lang10MainThread9call_mainEJvv+131>

Do I need to actually stop the process of stepping through the code before I hit
the crash in order to disassemble real_main? I tried...

(gdb) break ../../../gcc-4.5-20091128/libjava/gnu/java/lang/natMainThread.cc:46
Breakpoint 1 at 0x20c49ba4b0a5ab: file ../../../gcc-4.5-20091128/libjava/gnu/java/lang/natMainThread.cc, line 46.
(gdb) r testme.java -fbootclasspath=/sw/share/java/ecj/ecj.jar:./:/sw/lib/gcc4.5/share/java/libgcj-4.5.0.jar -fsource=1.5 -ftarget=1.5 -fzip-dependency /var/folders/1C/1CdoNxmNFHyOIjNBLNuJh++++TM/-Tmp-//ccQOWl1c.zip -fzip-target /var/folders/1C/1CdoNxmNFHyOIjNBLNuJh++++TM/-Tmp-//cc4p4DHj.jar
Starting program: /sw/lib/gcc4.5/libexec/gcc/x86_64-apple-darwin9.8.0/4.5.0/ecj1 testme.java -fbootclasspath=/sw/share/java/ecj/ecj.jar:./:/sw/lib/gcc4.5/share/java/libgcj-4.5.0.jar -fsource=1.5 -ftarget=1.5 -fzip-dependency /var/folders/1C/1CdoNxmNFHyOIjNBLNuJh++++TM/-Tmp-//ccQOWl1c.zip -fzip-target /var/folders/1C/1CdoNxmNFHyOIjNBLNuJh++++TM/-Tmp-//cc4p4DHj.jar
warning: posix_spawn failed, trying execvp, error: 86
Reading symbols for shared libraries +++++.. done
Breakpoint 1 at 0x1000485ab: file ../../../gcc-4.5-20091128/libjava/gnu/java/lang/natMainThread.cc, line 46.

Breakpoint 1, 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) s
Current language:  auto; currently c++
45	  else if (! ::java::lang::reflect::Modifier::isPublic(meth->accflags))
(gdb) s
54	  (*real_main) (args);
(gdb) bt  
#0  gnu::java::lang::MainThread::call_main (this=0x104875dc0) at ../../../gcc-4.5-20091128/libjava/gnu/java/lang/natMainThread.cc:54
#1  0x0000000104875dc0 in ?? () at ClassHelper.java:106
#2  0x0000000104875f00 in ?? () at ClassHelper.java:106
#3  0x000000010493e980 in ?? () at ClassHelper.java:106
#4  0x00000001000b1b74 in _ZN3gnu4java4lang10MainThread3runEJvv (this=0x104875dc0) at MainThread.java:106
Previous frame inner to this frame (gdb could not unwind past this frame)
(gdb) info line 54
Line 54 of "../../../gcc-4.5-20091128/libjava/gnu/java/lang/natMainThread.cc" starts at address 0x1000485b4 <_ZN3gnu4java4lang10MainThread9call_mainEJvv+196> and ends at 0x1000485be <_ZN3gnu4java4lang10MainThread9call_mainEJvv+206>.
(gdb) disassemble 0x1000485b4  0x1000485be
Dump of assembler code from 0x1000485b4 to 0x1000485be:
0x00000001000485b4 <_ZN3gnu4java4lang10MainThread9call_mainEJvv+196>:	mov    0x90(%rbx),%rdi
0x00000001000485bb <_ZN3gnu4java4lang10MainThread9call_mainEJvv+203>:	callq  *0x18(%rbp)
End of assembler dump.
(gdb) 

I'm not sure what to do at this point to disassemble the call destination...

(gdb) disassemble *0x18(%rbp)
A syntax error in expression, near `%rbp)'.
(gdb) disassemble 0x18(%rbp)
A syntax error in expression, near `%rbp)'.
(gdb) disassemble %rbp 
A syntax error in expression, near `%rbp'.

I am at the correct spot though since the next step causes the crash. Also I do
notice that the output from "disassemble 0x1000485b4  0x1000485be" is listed in
the longer disassembly from 0x00000001000485be.
                 Jack
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.