Nabble - gcc - java

FYI Patch: java/41991: Use -allow_stack_execute on Darwin

2009-12-09T10:55:03Z

On Sat, Dec 5, 2009 at 6:54 AM, Jack Howarth <howarth@...> wrote:

> Bryce,
> Your patch eliminates the crashes in gcj completely for gcc trunk
> on x86_64-apple-darwin9 if I also regress out r154282 and r154283
> so that the FSF libgcc's unwinder is used again. So we are starting
> to peel the layers off of the problem. Your patch definitely should
> go into gcc trunk and gcc 4.4 branch (where it will be immediately
> useful on darwin9 since the libgcc_ext changes don't exist there).

Thanks for testing, Jack. I have checked this patch in to both trunk
and 4.4 branch.

2009-12-09 Bryce McKinlay <bmckinlay@...>

PR java/41991
* configure.ac (SYSTEMSPEC): Pass -allow_stack_execute to Darwin
linker.
* Makefile.am (gij_LDFLAGS): Remove extra_gij_ldflags.
* configure: Regenerate.
* Makefile.in: Regenerate.

Bryce

libjava-darwin-stack.patch (7K) Download Attachment

Re: GC symbols no longer exported (on Debian) from libgcj 8 and up

2009-12-09T04:39:29Z

On Fri, Nov 27, 2009 at 10:25, Andrew Haley <aph@...> wrote:

>> If it was intentional, my question is how I can get access to the GC?
>
> The symbols exported are controlled by:
>
> if ANONVERSCRIPT
> extra_ldflags_libjava += -Wl,--version-script=$(srcdir)/libgcj.ver
> endif
>
> Which is:
>
> # Anonymous GNU ld version script to hide boehm-gc, libffi and fdlibm
> # symbols in libgcj.so.
>
> {
> global: Jv*; _Jv_*; __gcj_personality_v0; __gcj_personality_sj0; _Z*;
> local: *;
> };

Adding GC_*; to gloca

Re: [patch] Fix oddity in personality routine

2009-12-04T22:54:31Z

On Fri, Dec 04, 2009 at 03:57:11PM +0000, Bryce McKinlay wrote:

> On Fri, Dec 4, 2009 at 3:48 PM, Andrew Haley <aph@...> wrote:
>
> > Yes, which is why I suggested you use SYSTEMSPEC. (Twice now, I think. :-)
> >
> > SYSTEMSPEC should pass that flag to everything liked with gcj.
>
> Jack,
>
> Here's a patch that adds the allow_stack_execute flag to SYSTEMSPEC as
> suggested by Andrew.
>
> It does not fix the problem with ecj, but I agree it's a good idea.
>
> Bryce

Bryce,
Your patch eliminates the crashes in gcj completely for gcc trunk
on x86_64-apple-darwin9 if I also regress out r154282 and r154283
so that the FSF libgcc's unwinder is used again. So we are starting
to peel the layers off of the problem. Your patch definitely should
go into gcc trunk and gcc 4.4 branch (where it will be immediately
useful on darwin9 since the libgcc_ext changes don't exist there).
In case you are unaware, the r154282 and r154283 commits
introduced a new libgcc_ext shared library on darwin to provide
the additional symbols that have been added to libgcc since the
libgcc 10.4 and 10.5 stubs were defined. One 'feature' of this
change is that both the system libgcc and the FSF libgcc are linked
in. The logic is that since the 10.4/10.5 stubs are no longer built
on FSF gcc trunk, those symbols will be provided by the first
libgcc to be linked in (which is the system's). The second libgcc_s
linked in comes from FSF gcc and provides the additional symbols
via the 10.4/10.5 libgcc_ext stubs. Mike Stump approved the logic
of all of this.
I will revert back to the r154282 and r154283 commits being
in place under darwin9. When the system libgcc is used under
darwin9 (which is now the default behavior in gcc trunk for
darwin), gcj crashes with your patch in place when compiling
java code...

Breakpoint 1 (./../../gcc-4.5-20091204/libjava/exception.cc:128) pending.
(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-//ccamdOl5.zip -fzip-target /var/folders/1C/1CdoNxmNFHyOIjNBLNuJh++++TM/-Tmp-//ccaNqaGi.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-//ccamdOl5.zip -fzip-target /var/folders/1C/1CdoNxmNFHyOIjNBLNuJh++++TM/-Tmp-//ccaNqaGi.jar
warning: posix_spawn failed, trying execvp, error: 86
Reading symbols for shared libraries ++++.+. done

Program received signal SIGABRT, Aborted.
0x00007fff810c3f16 in __kill ()
(gdb) bt
#0 0x00007fff810c3f16 in __kill ()
#1 0x00007fff81134f6d in abort ()
#2 0x000000010001342b in _Jv_Throw (value=0x10483e6c0) at ../../../gcc-4.5-20091204/libjava/exception.cc:128
Previous frame inner to this frame (gdb could not unwind past this frame)

This crash appears to be different from that seen under darwin10. That might not be surprising as the
unwinder is a different one subsumed into libSystem in that case. Unfortunately it won't be trivial
to get debug code for the system unwinder. Hopefully, I can just use the approach of examining the
assembly at the address of the crash to define the scope of the problem in both darwin9 and darwin10.
In any case, we have made significant progress towards solving PR41991. Thanks in advance for
any help in getting your patch into gcc trunk and 4.4 branch as an obvious fix.
Jack

Re: [patch] Fix oddity in personality routine

2009-12-04T20:37:24Z

On Fri, Dec 04, 2009 at 03:57:11PM +0000, Bryce McKinlay wrote:

Bryce,
Your proposed patch builds libjava normally on x86_64-apple-darwin10
and I now see...

#
# This spec file is read by gcj when linking.
# It is used to specify the standard libraries we need in order
# to link with libgcj.
#
%rename startfile startfileorig
*startfile: %(startfileorig)

%rename lib liborig
*lib: %{s-bc-abi:} -lgcj -lm -L/sw/lib -liconv -lpthread -lz -allow_stack_execute -ldl %(libgcc) %(liborig)

*jc1: -fhash-synchronization -fuse-divide-subroutine -fcheck-references -fuse-boehm-gc -fnon-call-exceptions -fkeep-inline-functions

in /sw/lib/gcc4.5/lib/gcc/x86_64-apple-darwin10.2.0/4.5.0/../../../libgcj.spec instead of...

#
# This spec file is read by gcj when linking.
# It is used to specify the standard libraries we need in order
# to link with libgcj.
#
%rename startfile startfileorig
*startfile: %(startfileorig)

%rename lib liborig
*lib: %{s-bc-abi:} -lgcj -lm -L/sw/lib -liconv -lpthread -lz -ldl %(libgcc) %(liborig)

*jc1: -fhash-synchronization -fuse-divide-subroutine -fcheck-references -fuse-boehm-gc -fnon-call-exceptions -fkeep-inline-functions

Linking with gcj -v also reveals that -allow_stack_execute is being passed to collect2
as expected. Can we get this in to gcc trunk as an obvious change?
Jack
ps Gcj still crashes compiling java as I saw yesterday with the alternative approach to passing -stack_allow_execute...

[MacPro:~] howarth% gdb /sw/lib/gcc4.5/libexec/gcc/x86_64-apple-darwin10.2.0/4.5.0/ecj1
GNU gdb 6.3.50-20050815 (Apple version gdb-1346) (Fri Sep 18 20:40:51 UTC 2009)
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for details.
This GDB was configured as "x86_64-apple-darwin"...Reading symbols for shared libraries ...... done

warning: Could not find object file "/var/tmp//cckmtKiq.o" - no debug information available for "/var/tmp//cc4vWuF2.i".

(gdb) break ../../../gcc-4.5-20091204/libjava/gnu/classpath/natVMStackWalker.cc:104
Breakpoint 1 at 0x20c49ba4ad2864: file ../../../gcc-4.5-20091204/libjava/gnu/classpath/natVMStackWalker.cc, line 104.
Breakpoint 2 at 0x20c49ba4ad28a0: file ../../../gcc-4.5-20091204/libjava/gnu/classpath/natVMStackWalker.cc, line 104.
warning: Multiple breakpoints were set.
Use the "delete" command to delete unwanted breakpoints.
(gdb) r testme.java -fbootclasspath=/sw/share/java/ecj/ecj.jar:./:/sw/share/xtal/ccp4-6.1.2/bin/:/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-//ccf5cqZS.zip -fzip-target /var/folders/1C/1CdoNxmNFHyOIjNBLNuJh++++TM/-Tmp-//ccK4ZxH8.jar
Starting program: /sw/lib/gcc4.5/libexec/gcc/x86_64-apple-darwin10.2.0/4.5.0/ecj1 testme.java -fbootclasspath=/sw/share/java/ecj/ecj.jar:./:/sw/share/xtal/ccp4-6.1.2/bin/:/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-//ccf5cqZS.zip -fzip-target /var/folders/1C/1CdoNxmNFHyOIjNBLNuJh++++TM/-Tmp-//ccK4ZxH8.jar
Reading symbols for shared libraries +++++. done

Breakpoint 1, gnu::classpath::VMStackWalker::getCallingClassLoader (pc=0x10098d774) at ../../../gcc-4.5-20091204/libjava/gnu/classpath/natVMStackWalker.cc:104
104 jclass klass = GET_CALLING_CLASS(pc);
(gdb) s
Current language: auto; currently c++
0x0000000100994db2 in dyld_stub__Unwind_FindEnclosingFunction ()
(gdb) s
Single stepping until exit from function dyld_stub__Unwind_FindEnclosingFunction,
which has no line number information.
0x00007fff844bffc0 in _Unwind_FindEnclosingFunction ()
(gdb) s
Single stepping until exit from function _Unwind_FindEnclosingFunction,
which has no line number information.

Program received signal SIGABRT, Aborted.
0x00007fff843d4fe6 in __kill ()
(gdb)

I'll repeat this build on x86_64-apple-darwin9 tomorrow to verify that in both darwin9 and
darwin10 (with the proper passing of -allow_stack_execute) that the crash has moved to the
same location and update the PR. Thanks again for the patch.
Jack
ps After I verify that stock gcc trunk behaves the same under darwin9 with the above patch,
I'll rebuild gcc trunk with the libgcc_ext changes regressed out to verify that the FSF libgcc
and the system libgcc unwinder are both failing in the same manner on darwin9. This will also
allow me to walk the unwinder (as unfortunately Apple's libgcc and libSystem unwinders don't
ship with debug code...sigh).

Re: java.lang.NoClassDefFoundError: java.text.DecimalFormat

2009-12-04T10:10:29Z

Oh my, how embarrassing, that does make sense though, appreciate it :)

I'll update the thread with my progress....

Keith

Re: [patch] Fix oddity in personality routine

2009-12-04T08:06:39Z

Jack Howarth wrote:

> On Fri, Dec 04, 2009 at 03:48:03PM +0000, Andrew Haley wrote:
>> Jack Howarth wrote:
>>> On Fri, Dec 04, 2009 at 02:59:43PM +0000, Andrew Haley wrote:
>>>>> I suspect we may have a layered problem here and need
>>>>> to work through each section. This weekend, I do some additional
>>>>> builds to verify that the crash debugs to the same locations
>>>>> in both darwin9 and darwin10 with and without the proposed
>>>>> patch to pass -Wl,-allow_stack_execute on GCJLINK.
>>>> Right.
>>>>
>>> Andrew,
>>> Just to double check, you do agree that everything linked with
>>> GCJLINK should be passed -Wl,-allow_stack_execute on darwin9/darwin10?
>> I think so.
>>
>>> I am a bit confused by the criteria used to determine which java binaries
>>> need the ld flag for -allow_stack_execute. If the a shared library contains
>>> code that needs to execute on the stack
>> No gcj library needs to execute on the stack, only the heap. I think the flag
>> is misnamed.
>>
>>> (libgcj) shouldn't any executable
>>> that links in that shared lib use the -allow_stack_execute ld flag?
>> Yes, which is why I suggested you use SYSTEMSPEC. (Twice now, I think. :-)
>>
>> SYSTEMSPEC should pass that flag to everything liked with gcj.

> I tried SYSTEMSPEC last night and it didn't eliminate the crashes in gcj. I'll double
> check that tonight and specifically look for when libtool is using gcj to link to make
> sure the -allow_stack_execute flag is invoked. If so, I'll make sure that the location of
> the crash in gcj has shifted as it did when passing -Wl,-allow_stack_execute on GCJLINK.

OK.

> ps Should I take this to mean that SYSTEMSPEC will cause gcj to automatically pass
> -Wl,-allow_stack_execute when it links code? I assume I should be able to see that with
> -v being pased to gcj.

Yes. This should work everywhere, all the time.

> What confuses me is that gcj -v shows ejc1 being invoked.

Yes.

> So does ecj1 get the -Wl,-allow_stack_execute passed on from gcj or should it be invoking
> -Wl,-allow_stack_execute on its own from SYSTEMSPEC?

ecj1 doesn't get passed -allow_stack_execute, the linker does. Adding -allow_stack_execute
to SYSTEMSPEC will make sure that the linker is always passed this command.

Bryce's patch is right, I think.

Andrew.

Re: [patch] Fix oddity in personality routine

2009-12-04T07:59:15Z

On Fri, Dec 04, 2009 at 03:48:03PM +0000, Andrew Haley wrote:

> Jack Howarth wrote:
> > On Fri, Dec 04, 2009 at 02:59:43PM +0000, Andrew Haley wrote:
> >>> I suspect we may have a layered problem here and need
> >>> to work through each section. This weekend, I do some additional
> >>> builds to verify that the crash debugs to the same locations
> >>> in both darwin9 and darwin10 with and without the proposed
> >>> patch to pass -Wl,-allow_stack_execute on GCJLINK.
> >> Right.
> >>
> >
> > Andrew,
> > Just to double check, you do agree that everything linked with
> > GCJLINK should be passed -Wl,-allow_stack_execute on darwin9/darwin10?
>
> I think so.
>
> > I am a bit confused by the criteria used to determine which java binaries
> > need the ld flag for -allow_stack_execute. If the a shared library contains
> > code that needs to execute on the stack
>
> No gcj library needs to execute on the stack, only the heap. I think the flag
> is misnamed.
>
> > (libgcj) shouldn't any executable
> > that links in that shared lib use the -allow_stack_execute ld flag?
>
> Yes, which is why I suggested you use SYSTEMSPEC. (Twice now, I think. :-)
>
> SYSTEMSPEC should pass that flag to everything liked with gcj.
>
> Andrew.

Andrew,
I tried SYSTEMSPEC last night and it didn't eliminate the crashes in gcj. I'll double
check that tonight and specifically look for when libtool is using gcj to link to make
sure the -allow_stack_execute flag is invoked. If so, I'll make sure that the location of
the crash in gcj has shifted as it did when passing -Wl,-allow_stack_execute on GCJLINK.
Jack
ps Should I take this to mean that SYSTEMSPEC will cause gcj to automatically pass
-Wl,-allow_stack_execute when it links code? I assume I should be able to see that with
-v being pased to gcj. What confuses me is that gcj -v shows ejc1 being invoked. So
does ecj1 get the -Wl,-allow_stack_execute passed on from gcj or should it be invoking
-Wl,-allow_stack_execute on its own from SYSTEMSPEC?

Re: [patch] Fix oddity in personality routine

2009-12-04T07:57:11Z

On Fri, Dec 4, 2009 at 3:48 PM, Andrew Haley <aph@...> wrote:

> Yes, which is why I suggested you use SYSTEMSPEC. (Twice now, I think. :-)
>
> SYSTEMSPEC should pass that flag to everything liked with gcj.

Jack,

Here's a patch that adds the allow_stack_execute flag to SYSTEMSPEC as
suggested by Andrew.

It does not fix the problem with ecj, but I agree it's a good idea.

Bryce

libgcj-darwin-systemspec.patch (15K) Download Attachment

Re: [patch] Fix oddity in personality routine

2009-12-04T07:48:03Z

Jack Howarth wrote:

> On Fri, Dec 04, 2009 at 02:59:43PM +0000, Andrew Haley wrote:
>>> I suspect we may have a layered problem here and need
>>> to work through each section. This weekend, I do some additional
>>> builds to verify that the crash debugs to the same locations
>>> in both darwin9 and darwin10 with and without the proposed
>>> patch to pass -Wl,-allow_stack_execute on GCJLINK.
>> Right.
>>
>
> Andrew,
> Just to double check, you do agree that everything linked with
> GCJLINK should be passed -Wl,-allow_stack_execute on darwin9/darwin10?

I think so.

> I am a bit confused by the criteria used to determine which java binaries
> need the ld flag for -allow_stack_execute. If the a shared library contains
> code that needs to execute on the stack

No gcj library needs to execute on the stack, only the heap. I think the flag
is misnamed.

> (libgcj) shouldn't any executable
> that links in that shared lib use the -allow_stack_execute ld flag?

Yes, which is why I suggested you use SYSTEMSPEC. (Twice now, I think. :-)

SYSTEMSPEC should pass that flag to everything liked with gcj.

Andrew.

Re: [patch] Fix oddity in personality routine

2009-12-04T07:23:47Z

On Fri, Dec 04, 2009 at 02:59:43PM +0000, Andrew Haley wrote:
>
> > I suspect we may have a layered problem here and need
> > to work through each section. This weekend, I do some additional
> > builds to verify that the crash debugs to the same locations
> > in both darwin9 and darwin10 with and without the proposed
> > patch to pass -Wl,-allow_stack_execute on GCJLINK.
>
> Right.
>

Andrew,
Just to double check, you do agree that everything linked with
GCJLINK should be passed -Wl,-allow_stack_execute on darwin9/darwin10?
I am a bit confused by the criteria used to determine which java binaries
need the ld flag for -allow_stack_execute. If the a shared library contains
code that needs to execute on the stack (libgcj) shouldn't any executable
that links in that shared lib use the -allow_stack_execute ld flag?
Jack

Re: [patch] Fix oddity in personality routine

2009-12-04T06:59:43Z

Jack Howarth wrote:

> On Fri, Dec 04, 2009 at 09:44:29AM +0000, Andrew Haley wrote:
>> Jack Howarth wrote:
>>> Using the patch...
>> Let's see the compile time output, when the executables were linked.
>>
>>> This is interesting since on x86_64-apple-darwin10, we have been failing...
>>>
>>> FAIL: WalkerTest execution - source compiled test
>>> FAIL: WalkerTest -findirect-dispatch execution - source compiled test
>>> FAIL: WalkerTest -O3 execution - source compiled test
>>> FAIL: WalkerTest -O3 -findirect-dispatch execution - source compiled test
>> Since when? You didn't mention this before.

> I believe we have been seeing the additional WalkerTest
> failures under darwin10 ever since gcc trunk was fixed so
> that darwin10 built with stack execution like darwin9...
>
> http://gcc.gnu.org/ml/gcc-patches/2008-11/msg01532.html

OK. I'm pretty sure this is a different failure.

> However this may all be a red herring because x86_64-apple-darwin9
> (which doesn't show these WalkerTest failures) shows the
> same issue with gcj crashing when compiling java code.
> I suspect we may have a layered problem here and need
> to work through each section. This weekend, I do some additional
> builds to verify that the crash debugs to the same locations
> in both darwin9 and darwin10 with and without the proposed
> patch to pass -Wl,-allow_stack_execute on GCJLINK.

Right.

> The WalkerTest failures in darwin10 may be orthogonal to
> the issue of gcj crashing since they don't occur in darwin9
> and darwin9 has the gcj issue as well. I'll do some builds this
> weekend to verify that...
>
> 1) x86_64-apple-darwin9 still passes the WalkerTests
> 2) x86_64-apple-darwin9 and x86_64-apple-darwin10 both backtrace
> to the same place when gcj crashes compiling java code.
> 3) When the GCJLINK to patched to always pass -Wl,-allow_stack_execute
> that the backtrace moves to the same place in both x86_64-apple-darwin9
> and x86_64-apple-darwin10.

Do you see the same page fault once -Wl,-allow_stack_execute is used?
If not, this one is fixed, and we can look at the unwinder fproblem.

> 4) I'll also back out the libgcc-ext patch completely and verify that
> x86_64-apple-darwin9 crashes at the same locations for step 2 and 3.
> This will verify that the system unwinder and the FSF libgcc unwinder
> both behave the same in these gcj crashes.

> ps As I mentioned before, darwin10 uses an unwinder in libSystem which
> is derived from that in gcc 4.2.1. Also, since the libgcc_ext patch
> went into gcc trunk, darwin9 also links in the system libgcc_s.10.5
> before the FSF libgcc_s so that it also now uses the system unwinder
> (from libgcc). However note that thse gcj crashes predate all of this.
> I have verified that they go as far back as gcc 4.3.4.

OK. So, we may have just one bug left rather than two. Here's hoping.

Andrew.

Re: [patch] Fix oddity in personality routine

2009-12-04T06:51:45Z

On Fri, Dec 04, 2009 at 09:44:29AM +0000, Andrew Haley wrote:

> Jack Howarth wrote:
> > Using the patch...
>
> Let's see the compile time output, when the executables were linked.
>
> > This is interesting since on x86_64-apple-darwin10, we have been failing...
> >
> > FAIL: WalkerTest execution - source compiled test
> > FAIL: WalkerTest -findirect-dispatch execution - source compiled test
> > FAIL: WalkerTest -O3 execution - source compiled test
> > FAIL: WalkerTest -O3 -findirect-dispatch execution - source compiled test
>
> Since when? You didn't mention this before.
>
> Andrew.

Andrew,
I believe we have been seeing the additional WalkerTest
failures under darwin10 ever since gcc trunk was fixed so
that darwin10 built with stack execution like darwin9...

http://gcc.gnu.org/ml/gcc-patches/2008-11/msg01532.html

However this may all be a red herring because x86_64-apple-darwin9
(which doesn't show these WalkerTest failures) shows the
same issue with gcj crashing when compiling java code.
I suspect we may have a layered problem here and need
to work through each section. This weekend, I do some additional
builds to verify that the crash debugs to the same locations
in both darwin9 and darwin10 with and without the proposed
patch to pass -Wl,-allow_stack_execute on GCJLINK.
The WalkerTest failures in darwin10 may be orthogonal to
the issue of gcj crashing since they don't occur in darwin9
and darwin9 has the gcj issue as well. I'll do some builds this
weekend to verify that...

1) x86_64-apple-darwin9 still passes the WalkerTests
2) x86_64-apple-darwin9 and x86_64-apple-darwin10 both backtrace
to the same place when gcj crashes compiling java code.
3) When the GCJLINK to patched to always pass -Wl,-allow_stack_execute
that the backtrace moves to the same place in both x86_64-apple-darwin9
and x86_64-apple-darwin10.
4) I'll also back out the libgcc-ext patch completely and verify that
x86_64-apple-darwin9 crashes at the same locations for step 2 and 3.
This will verify that the system unwinder and the FSF libgcc unwinder
both behave the same in these gcj crashes.
Jack
ps As I mentioned before, darwin10 uses an unwinder in libSystem which
is derived from that in gcc 4.2.1. Also, since the libgcc_ext patch
went into gcc trunk, darwin9 also links in the system libgcc_s.10.5
before the FSF libgcc_s so that it also now uses the system unwinder
(from libgcc). However note that thse gcj crashes predate all of this.
I have verified that they go as far back as gcc 4.3.4.

Re: java.lang.NoClassDefFoundError: java.text.DecimalFormat

2009-12-04T01:46:52Z

Keith Boynton wrote:

> Hi guys,
>
> Sorry for the delay in providing some feedback, I was trying to resolve some
> nuances in the Java Native Compiler that were making it difficult to specify
> the flags in the correct order. I was unable to resolve that, so I switched
> to straight command line entry.
>
> I tried your suggestion, here's the full command:
>
> 1. cd to src tree containing the .java source
> 2. Execute the following: C:\JavaNC\gcc-122233-win\bin\gcj -o
> C:\JavaNC\projects\Test\compiled\test.exe -Wl,--whole-archive -lgcj_properties
> -Wl,--no-whole-archive -static-libgcj --main=Test
>
> This gives me the following error at compile time:
> C:\Users\KEITHB~1\AppData\Local\Temp/ccw9aaaa.o: In function
> `main':C:/Users/KEITHB~1/AppData/Local/Temp/ccCuaaaa.i:(.text+0x25):
> undefined reference to `Test::class$$'
> collect2: ld returned 1 exit status

You haven't given gcj anything to compile. :-)

Andrew.

Re: [patch] Fix oddity in personality routine

2009-12-04T01:45:04Z

Jack Howarth wrote:

> On Thu, Dec 03, 2009 at 09:25:11PM +0000, Andrew Haley wrote:
>> Boehm, Hans wrote:
>>>> From: Jack Howarth
>>>> Do you think that -Wl,-allow_stack_execute needs to be
>>>> passed even more widely than on just ecjx_LDFLAGS? Any
>>>> suggestions as to where I should be passing it? Perhaps on
>>>> something like LIBJAVA_LDFLAGS_NOUNDEF at the toplevel of
>>>> libjava? Or should we even be building libffi and boehm-gc
>>>> with that as well?
>>>>
>>> I haven't been following this completely, but:
>>>
>>> The GC also has a compile-time flag NO_EXECUTE_PERMISSION, which affects heap executability.
>> I think that's probably not the cause, since libffi allocates memory itself.
>>
>> Andrew.
>
> Andrew,
> On reflection, shouldn't something like...
>
> Index: libjava/Makefile.in
> ===================================================================
> --- libjava/Makefile.in (revision 154965)
> +++ libjava/Makefile.in (working copy)
> @@ -8500,8 +8500,7 @@
> $(am__append_28)
> gij_SOURCES =
> gij_LDFLAGS = -rpath $(dbexecdir) -rpath $(toolexeclibdir) \
> - -shared-libgcc $(THREADLDFLAGS) $(extra_ldflags) \
> - $(extra_gij_ldflags)
> + -shared-libgcc $(THREADLDFLAGS) $(extra_ldflags)
>
> gij_LINK = $(GCJLINK) $(gij_LDFLAGS)
> gij_LDADD = -L$(here)/.libs libgij.la
> Index: libjava/Makefile.am
> ===================================================================
> --- libjava/Makefile.am (revision 154965)
> +++ libjava/Makefile.am (working copy)
> @@ -294,7 +294,7 @@
>
> LTLDFLAGS = $(shell $(top_srcdir)/../libtool-ldflags $(LDFLAGS))
> GCJLINK = $(LIBTOOL) --tag=GCJ $(LIBTOOLFLAGS) --mode=link $(GCJ) -L$(here) \
> - $(JC1FLAGS) $(LTLDFLAGS) -o $@
> + $(extra_gij_ldflags) $(JC1FLAGS) $(LTLDFLAGS) -o $@
> GCJ_FOR_ECJX = @GCJ_FOR_ECJX@
> GCJ_FOR_ECJX_LINK = $(GCJ_FOR_ECJX) -o $@
> LIBLINK = $(LIBTOOL) --tag=CXX $(LIBTOOLFLAGS) --mode=link $(CXX) -L$(here) \
> @@ -1065,8 +1065,7 @@
> ## need this because we are explicitly using libtool to link using the
> ## `.la' file.
> gij_LDFLAGS = -rpath $(dbexecdir) -rpath $(toolexeclibdir) \
> - -shared-libgcc $(THREADLDFLAGS) $(extra_ldflags) \
> - $(extra_gij_ldflags)
> + -shared-libgcc $(THREADLDFLAGS) $(extra_ldflags)
> gij_LINK = $(GCJLINK) $(gij_LDFLAGS)
> ## See jv_convert_LDADD.
> gij_LDADD = -L$(here)/.libs libgij.la
>
> ...be appropriate to make sure that all java executables on darwin are linked with
> -Wl,-allow_stack_execute?

No, because it will only affect the binaries in gcj, not things the
user compiles. That's why I suggested SYSTEMSPEC.

Andrew.

Re: [patch] Fix oddity in personality routine

2009-12-04T01:44:29Z

Jack Howarth wrote:
> Using the patch...

Let's see the compile time output, when the executables were linked.

> This is interesting since on x86_64-apple-darwin10, we have been failing...
>
> FAIL: WalkerTest execution - source compiled test
> FAIL: WalkerTest -findirect-dispatch execution - source compiled test
> FAIL: WalkerTest -O3 execution - source compiled test
> FAIL: WalkerTest -O3 -findirect-dispatch execution - source compiled test

Since when? You didn't mention this before.

Andrew.

Re: java.lang.NoClassDefFoundError: java.text.DecimalFormat

2009-12-04T00:34:10Z

Hi guys,

Sorry for the delay in providing some feedback, I was trying to resolve some
nuances in the Java Native Compiler that were making it difficult to specify
the flags in the correct order. I was unable to resolve that, so I switched
to straight command line entry.

I tried your suggestion, here's the full command:

1. cd to src tree containing the .java source
2. Execute the following: C:\JavaNC\gcc-122233-win\bin\gcj -o
C:\JavaNC\projects\Test\compiled\test.exe -Wl,--whole-archive -lgcj_properties
-Wl,--no-whole-archive -static-libgcj --main=Test

This gives me the following error at compile time:
C:\Users\KEITHB~1\AppData\Local\Temp/ccw9aaaa.o: In function
`main':C:/Users/KEITHB~1/AppData/Local/Temp/ccCuaaaa.i:(.text+0x25):
undefined reference to `Test::class$$'
collect2: ld returned 1 exit status

Any help would be greatly appreciated

Keith

Re: [patch] Fix oddity in personality routine

2009-12-03T20:12:38Z

Using the patch...

Index: libjava/Makefile.in
===================================================================
--- libjava/Makefile.in (revision 154965)
+++ libjava/Makefile.in (working copy)
@@ -1070,7 +1070,7 @@
GCJ_WITH_FLAGS = $(GCJ) --encoding=UTF-8 -Wno-deprecated
LTLDFLAGS = $(shell $(top_srcdir)/../libtool-ldflags $(LDFLAGS))
GCJLINK = $(LIBTOOL) --tag=GCJ $(LIBTOOLFLAGS) --mode=link $(GCJ) -L$(here) \
- $(JC1FLAGS) $(LTLDFLAGS) -o $@
+ $(extra_gij_ldflags) $(JC1FLAGS) $(LTLDFLAGS) -o $@

GCJ_FOR_ECJX_LINK = $(GCJ_FOR_ECJX) -o $@
LIBLINK = $(LIBTOOL) --tag=CXX $(LIBTOOLFLAGS) --mode=link $(CXX) -L$(here) \
@@ -8500,8 +8500,7 @@
$(am__append_28)
gij_SOURCES =
gij_LDFLAGS = -rpath $(dbexecdir) -rpath $(toolexeclibdir) \
- -shared-libgcc $(THREADLDFLAGS) $(extra_ldflags) \
- $(extra_gij_ldflags)
+ -shared-libgcc $(THREADLDFLAGS) $(extra_ldflags)

gij_LINK = $(GCJLINK) $(gij_LDFLAGS)
gij_LDADD = -L$(here)/.libs libgij.la
Index: libjava/Makefile.am
===================================================================
--- libjava/Makefile.am (revision 154965)
+++ libjava/Makefile.am (working copy)
@@ -294,7 +294,7 @@

LTLDFLAGS = $(shell $(top_srcdir)/../libtool-ldflags $(LDFLAGS))
GCJLINK = $(LIBTOOL) --tag=GCJ $(LIBTOOLFLAGS) --mode=link $(GCJ) -L$(here) \
- $(JC1FLAGS) $(LTLDFLAGS) -o $@
+ $(extra_gij_ldflags) $(JC1FLAGS) $(LTLDFLAGS) -o $@
GCJ_FOR_ECJX = @GCJ_FOR_ECJX@
GCJ_FOR_ECJX_LINK = $(GCJ_FOR_ECJX) -o $@
LIBLINK = $(LIBTOOL) --tag=CXX $(LIBTOOLFLAGS) --mode=link $(CXX) -L$(here) \
@@ -1065,8 +1065,7 @@
## need this because we are explicitly using libtool to link using the
## `.la' file.
gij_LDFLAGS = -rpath $(dbexecdir) -rpath $(toolexeclibdir) \
- -shared-libgcc $(THREADLDFLAGS) $(extra_ldflags) \
- $(extra_gij_ldflags)
+ -shared-libgcc $(THREADLDFLAGS) $(extra_ldflags)
gij_LINK = $(GCJLINK) $(gij_LDFLAGS)
## See jv_convert_LDADD.
gij_LDADD = -L$(here)/.libs libgij.la

The crash in gcj still occurs but it may have moved location (I am under darwin10
at the moment). I see...

gdb /sw/lib/gcc4.5/libexec/gcc/x86_64-apple-darwin10.2.0/4.5.0/ecj1
(gdb) r testme.java -fbootclasspath=/sw/share/java/ecj/ecj.jar:./:/sw/share/xtal/ccp4-6.1.2/bin/:/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-//cc3tiRxo.zip -fzip-target /var/folders/1C/1CdoNxmNFHyOIjNBLNuJh++++TM/-Tmp-//ccsmjxPB.jar
Starting program: /sw/lib/gcc4.5/libexec/gcc/x86_64-apple-darwin10.2.0/4.5.0/ecj1 testme.java -fbootclasspath=/sw/share/java/ecj/ecj.jar:./:/sw/share/xtal/ccp4-6.1.2/bin/:/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-//cc3tiRxo.zip -fzip-target /var/folders/1C/1CdoNxmNFHyOIjNBLNuJh++++TM/-Tmp-//ccsmjxPB.jar
Reading symbols for shared libraries +++++. done

Program received signal SIGABRT, Aborted.
0x00007fff843d4fe6 in __kill ()
(gdb) bt
#0 0x00007fff843d4fe6 in __kill ()
#1 0x00007fff84475e32 in abort ()
#2 0x00007fff844bffc9 in _Unwind_FindEnclosingFunction ()
#3 0x000000010001091c in gnu::classpath::VMStackWalker::getCallingClassLoader (pc=0x10098c8ac) at ../../../gcc-4.5-20091203/libjava/gnu/classpath/natVMStackWalker.cc:104
Previous frame inner to this frame (gdb could not unwind past this frame)
(gdb) x/10i 0x000000010001091c
0x10001091c <_ZN3gnu9classpath13VMStackWalker21getCallingClassLoaderEJPN4java4lang11ClassLoaderEPNS_3gcj7RawDataE+28>: mov %rax,%rbx
0x10001091f <_ZN3gnu9classpath13VMStackWalker21getCallingClassLoaderEJPN4java4lang11ClassLoaderEPNS_3gcj7RawDataE+31>: callq 0x100005cd0 <_ZN14_Jv_StackTrace14UpdateNCodeMapEv>
0x100010924 <_ZN3gnu9classpath13VMStackWalker21getCallingClassLoaderEJPN4java4lang11ClassLoaderEPNS_3gcj7RawDataE+36>: lea 0x1c7b4b5(%rip),%rax # 0x101c8bde0 <_ZN14_Jv_StackTrace8ncodeMapE>
0x10001092b <_ZN3gnu9classpath13VMStackWalker21getCallingClassLoaderEJPN4java4lang11ClassLoaderEPNS_3gcj7RawDataE+43>: mov %rbx,%rsi
0x10001092e <_ZN3gnu9classpath13VMStackWalker21getCallingClassLoaderEJPN4java4lang11ClassLoaderEPNS_3gcj7RawDataE+46>: mov (%rax),%rdi
0x100010931 <_ZN3gnu9classpath13VMStackWalker21getCallingClassLoaderEJPN4java4lang11ClassLoaderEPNS_3gcj7RawDataE+49>: mov (%rdi),%rdx
0x100010934 <_ZN3gnu9classpath13VMStackWalker21getCallingClassLoaderEJPN4java4lang11ClassLoaderEPNS_3gcj7RawDataE+52>: callq *0x60(%rdx)
0x100010937 <_ZN3gnu9classpath13VMStackWalker21getCallingClassLoaderEJPN4java4lang11ClassLoaderEPNS_3gcj7RawDataE+55>: test %rax,%rax
0x10001093a <_ZN3gnu9classpath13VMStackWalker21getCallingClassLoaderEJPN4java4lang11ClassLoaderEPNS_3gcj7RawDataE+58>: je 0x100010950 <_ZN3gnu9classpath13VMStackWalker21getCallingClassLoaderEJPN4java4lang11ClassLoaderEPNS_3gcj7RawDataE+80>
0x10001093c <_ZN3gnu9classpath13VMStackWalker21getCallingClassLoaderEJPN4java4lang11ClassLoaderEPNS_3gcj7RawDataE+60>: mov 0xa8(%rax),%rax

This is interesting since on x86_64-apple-darwin10, we have been failing...

FAIL: WalkerTest execution - source compiled test
FAIL: WalkerTest -findirect-dispatch execution - source compiled test
FAIL: WalkerTest -O3 execution - source compiled test
FAIL: WalkerTest -O3 -findirect-dispatch execution - source compiled test

in the libjava testsuite.
Jack

Re: [patch] Fix oddity in personality routine

2009-12-03T18:59:43Z

On Thu, Dec 03, 2009 at 09:25:11PM +0000, Andrew Haley wrote:

> Boehm, Hans wrote:
> >> From: Jack Howarth
> >> Do you think that -Wl,-allow_stack_execute needs to be
> >> passed even more widely than on just ecjx_LDFLAGS? Any
> >> suggestions as to where I should be passing it? Perhaps on
> >> something like LIBJAVA_LDFLAGS_NOUNDEF at the toplevel of
> >> libjava? Or should we even be building libffi and boehm-gc
> >> with that as well?
> >>
> > I haven't been following this completely, but:
> >
> > The GC also has a compile-time flag NO_EXECUTE_PERMISSION, which affects heap executability.
>
> I think that's probably not the cause, since libffi allocates memory itself.
>
> Andrew.

Andrew,
On reflection, shouldn't something like...

Index: libjava/Makefile.in
===================================================================
--- libjava/Makefile.in (revision 154965)
+++ libjava/Makefile.in (working copy)
@@ -8500,8 +8500,7 @@
$(am__append_28)
gij_SOURCES =
gij_LDFLAGS = -rpath $(dbexecdir) -rpath $(toolexeclibdir) \
- -shared-libgcc $(THREADLDFLAGS) $(extra_ldflags) \
- $(extra_gij_ldflags)
+ -shared-libgcc $(THREADLDFLAGS) $(extra_ldflags)

gij_LINK = $(GCJLINK) $(gij_LDFLAGS)
gij_LDADD = -L$(here)/.libs libgij.la
Index: libjava/Makefile.am
===================================================================
--- libjava/Makefile.am (revision 154965)
+++ libjava/Makefile.am (working copy)
@@ -294,7 +294,7 @@

LTLDFLAGS = $(shell $(top_srcdir)/../libtool-ldflags $(LDFLAGS))
GCJLINK = $(LIBTOOL) --tag=GCJ $(LIBTOOLFLAGS) --mode=link $(GCJ) -L$(here) \
- $(JC1FLAGS) $(LTLDFLAGS) -o $@
+ $(extra_gij_ldflags) $(JC1FLAGS) $(LTLDFLAGS) -o $@
GCJ_FOR_ECJX = @GCJ_FOR_ECJX@
GCJ_FOR_ECJX_LINK = $(GCJ_FOR_ECJX) -o $@
LIBLINK = $(LIBTOOL) --tag=CXX $(LIBTOOLFLAGS) --mode=link $(CXX) -L$(here) \
@@ -1065,8 +1065,7 @@
## need this because we are explicitly using libtool to link using the
## `.la' file.
gij_LDFLAGS = -rpath $(dbexecdir) -rpath $(toolexeclibdir) \
- -shared-libgcc $(THREADLDFLAGS) $(extra_ldflags) \
- $(extra_gij_ldflags)
+ -shared-libgcc $(THREADLDFLAGS) $(extra_ldflags)
gij_LINK = $(GCJLINK) $(gij_LDFLAGS)
## See jv_convert_LDADD.
gij_LDADD = -L$(here)/.libs libgij.la

...be appropriate to make sure that all java executables on darwin are linked with
-Wl,-allow_stack_execute? However, this raises the question of why the gcj and ecj1
compilers aren't doing the same? As I understand this, any executables created
with libraries containing code that executes on the stack (like libgcj) needs
to link the binaries with -Wl,-allow_stack_execute. Shouldn't this apply to
gcj and ecj1 as well since they create executables which are linked against
libgcj? Wouldn't we have to do this by adding the missing -allow_stack_execute flag
to libjava/libgcj.spec.in?
Jack

Re: [patch] Fix oddity in personality routine

2009-12-03T13:25:11Z

Boehm, Hans wrote:

>> From: Jack Howarth
>> Do you think that -Wl,-allow_stack_execute needs to be
>> passed even more widely than on just ecjx_LDFLAGS? Any
>> suggestions as to where I should be passing it? Perhaps on
>> something like LIBJAVA_LDFLAGS_NOUNDEF at the toplevel of
>> libjava? Or should we even be building libffi and boehm-gc
>> with that as well?
>>
> I haven't been following this completely, but:
>
> The GC also has a compile-time flag NO_EXECUTE_PERMISSION, which affects heap executability.

I think that's probably not the cause, since libffi allocates memory itself.

Andrew.

RE: [patch] Fix oddity in personality routine

2009-12-03T11:18:16Z

> From: Jack Howarth
> Do you think that -Wl,-allow_stack_execute needs to be
> passed even more widely than on just ecjx_LDFLAGS? Any
> suggestions as to where I should be passing it? Perhaps on
> something like LIBJAVA_LDFLAGS_NOUNDEF at the toplevel of
> libjava? Or should we even be building libffi and boehm-gc
> with that as well?
> Jack
>
>

I haven't been following this completely, but:

The GC also has a compile-time flag NO_EXECUTE_PERMISSION, which affects heap executability. I think the documentation says that this only affects incremental collection, but looking at the code, I'm not sure I believe that anymore. I think it generally affects whether memory allocated with mmap is made executable, and we've been doing more and more of that.

Hans

Re: [patch] Fix oddity in personality routine

2009-12-03T06:10:34Z

Jack Howarth wrote:
> On Thu, Dec 03, 2009 at 10:25:30AM +0000, Andrew Haley wrote:
>> Jack Howarth wrote:
>>> On Wed, Dec 02, 2009 at 09:34:33AM +0000, Andrew Haley wrote:
>>>> 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:

>>>
>>> What do you make of the bad assembly at 0x103f05dd1?
>> There is no bad assembly: there's a jump at 0x103f05dc5.
>>
>> I know what's going on.
>>
>> The OS forbids execution of memory in the heap. But, there is an extra
>> flag, -Wl,-allow_stack_execute, that allows this permission. This is
>> a misnamed flag, since we never execute code on the stack. I think it's
>> really controlling heap execution, not stack execution.
>>
>> We need to pass this flag everywhere, whenever a program is compiled by
>> gcj.
>>
>> Andrew.
>
> Andrew,
> This sounds like the patch that Andreas proposed in...
>
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41991#c3
>
> which didn't solve the problem on my MacPro or MacBook Pro
> under darwin9 or darwin10. He also ran into the issue again
> later...
>
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41991#c17
>
> Do you think that -Wl,-allow_stack_execute needs to be passed
> even more widely than on just ecjx_LDFLAGS? Any suggestions as
> to where I should be passing it? Perhaps on something like
> LIBJAVA_LDFLAGS_NOUNDEF at the toplevel of libjava? Or should
> we even be building libffi and boehm-gc with that as well?

I don't see =-Wl,-allow_stack_execute passed to anything except
when linking gij. That's why IMO gij works but nothing else does.

This needs to be everywhere, for all programs. I think SYSTEMSPEC
would do it, or add a new linker configure variable.

Andrew.

Re: [patch] Fix oddity in personality routine

2009-12-03T06:03:34Z

On Thu, Dec 03, 2009 at 10:25:30AM +0000, Andrew Haley wrote:

> Jack Howarth wrote:
> > On Wed, Dec 02, 2009 at 09:34:33AM +0000, Andrew Haley wrote:
> >> 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.
> >
> > Andrew,
> > Okay, I see...
> >
> > gdb /sw/lib/gcc4.5/libexec/gcc/x86_64-apple-darwin9.8.0/4.5.0/ecj1
> > ...
> > 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) x/10i 0x0000000103f05db0
> > 0x103f05db0: mov $0x1009814e8,%r11
> > 0x103f05dba: mov $0x103f05db0,%r10
> > 0x103f05dc4: clc
> > 0x103f05dc5: rex.WB jmpq *%r11
> > 0x103f05dc8: add %bl,-0x10(%rsi)
> > 0x103f05dcb: add (%rcx),%eax
> > 0x103f05dcd: add %al,(%rax)
> > 0x103f05dcf: add %ah,%al
> > 0x103f05dd1: (bad)
> > 0x103f05dd2: cwtl
> > (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) p $rax
> > $1 = 1
> >
> > (gdb) s
> >
> > Program received signal EXC_BAD_ACCESS, Could not access memory.
> > Reason: KERN_PROTECTION_FAILURE at address: 0x0000000103f05db0
> > 0x0000000103f05db0 in ?? () at ClassHelper.java:106
> > 106 ClassHelper.java: No such file or directory.
> > in ClassHelper.java
> >
> > What do you make of the bad assembly at 0x103f05dd1?
>
> There is no bad assembly: there's a jump at 0x103f05dc5.
>
> I know what's going on.
>
> The OS forbids execution of memory in the heap. But, there is an extra
> flag, -Wl,-allow_stack_execute, that allows this permission. This is
> a misnamed flag, since we never execute code on the stack. I think it's
> really controlling heap execution, not stack execution.
>
> We need to pass this flag everywhere, whenever a program is compiled by
> gcj.
>
> Andrew.

Andrew,
This sounds like the patch that Andreas proposed in...

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41991#c3

which didn't solve the problem on my MacPro or MacBook Pro
under darwin9 or darwin10. He also ran into the issue again
later...

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41991#c17

Do you think that -Wl,-allow_stack_execute needs to be passed
even more widely than on just ecjx_LDFLAGS? Any suggestions as
to where I should be passing it? Perhaps on something like
LIBJAVA_LDFLAGS_NOUNDEF at the toplevel of libjava? Or should
we even be building libffi and boehm-gc with that as well?
Jack

Re: [patch] Fix oddity in personality routine

2009-12-03T02:25:30Z

Jack Howarth wrote:

> On Wed, Dec 02, 2009 at 09:34:33AM +0000, Andrew Haley wrote:
>> 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.
>
> Andrew,
> Okay, I see...
>
> gdb /sw/lib/gcc4.5/libexec/gcc/x86_64-apple-darwin9.8.0/4.5.0/ecj1
> ...
> 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) x/10i 0x0000000103f05db0
> 0x103f05db0: mov $0x1009814e8,%r11
> 0x103f05dba: mov $0x103f05db0,%r10
> 0x103f05dc4: clc
> 0x103f05dc5: rex.WB jmpq *%r11
> 0x103f05dc8: add %bl,-0x10(%rsi)
> 0x103f05dcb: add (%rcx),%eax
> 0x103f05dcd: add %al,(%rax)
> 0x103f05dcf: add %ah,%al
> 0x103f05dd1: (bad)
> 0x103f05dd2: cwtl
> (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) p $rax
> $1 = 1
>
> (gdb) s
>
> Program received signal EXC_BAD_ACCESS, Could not access memory.
> Reason: KERN_PROTECTION_FAILURE at address: 0x0000000103f05db0
> 0x0000000103f05db0 in ?? () at ClassHelper.java:106
> 106 ClassHelper.java: No such file or directory.
> in ClassHelper.java
>
> What do you make of the bad assembly at 0x103f05dd1?

There is no bad assembly: there's a jump at 0x103f05dc5.

I know what's going on.

The OS forbids execution of memory in the heap. But, there is an extra
flag, -Wl,-allow_stack_execute, that allows this permission. This is
a misnamed flag, since we never execute code on the stack. I think it's
really controlling heap execution, not stack execution.

We need to pass this flag everywhere, whenever a program is compiled by
gcj.

Andrew.

Re: [patch] Fix oddity in personality routine

2009-12-02T17:08:28Z

On Wed, Dec 02, 2009 at 09:34:33AM +0000, Andrew Haley wrote:

> 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.

Andrew,
Okay, I see...

gdb /sw/lib/gcc4.5/libexec/gcc/x86_64-apple-darwin9.8.0/4.5.0/ecj1
...
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) x/10i 0x0000000103f05db0
0x103f05db0: mov $0x1009814e8,%r11
0x103f05dba: mov $0x103f05db0,%r10
0x103f05dc4: clc
0x103f05dc5: rex.WB jmpq *%r11
0x103f05dc8: add %bl,-0x10(%rsi)
0x103f05dcb: add (%rcx),%eax
0x103f05dcd: add %al,(%rax)
0x103f05dcf: add %ah,%al
0x103f05dd1: (bad)
0x103f05dd2: cwtl
(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) p $rax
$1 = 1

(gdb) s

Program received signal EXC_BAD_ACCESS, Could not access memory.
Reason: KERN_PROTECTION_FAILURE at address: 0x0000000103f05db0
0x0000000103f05db0 in ?? () at ClassHelper.java:106
106 ClassHelper.java: No such file or directory.
in ClassHelper.java

What do you make of the bad assembly at 0x103f05dd1?
Jack

Re: [patch] Fix oddity in personality routine

2009-12-02T01:34:33Z

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.

Re: [patch] Fix oddity in personality routine

2009-12-01T15:29:39Z

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

Re: PATCH, libjava: silence more warnings

2009-12-01T12:15:46Z

Tom Tromey wrote:

>>>>>> "Dave" == Dave Korn <dave.korn.cygwin@...> writes:
>
> Dave> Ben Elliston wrote:
>>> ::java::lang::String *
>>> -java::net::VMURLConnection::guessContentTypeFromBuffer (jbyteArray bytes,
>>> - jint valid)
>>> +java::net::VMURLConnection::guessContentTypeFromBuffer (jbyteArray bytes __attribute__ ((unused)),
>>> + jint valid __attribute__ ((unused)))
>
> Dave> There's a #define MAYBE_UNUSED in include/jvm.h, as used in
> Dave> java/lang/natClass.cc. But maybe jvm.h isn't available here?
>
> It is ok to include jvm.h from any of the CNI code.
>
> But, it is also ok to just use an unadorned __attribute__. We know this
> code can only be compiled by g++.

... given which, it's hardly worth adding a new header dependency just to
get the macro. Right, thanks for clarifying that.

cheers,
DaveK

Re: PATCH, libjava: silence more warnings

2009-12-01T11:44:12Z

>>>>> "Dave" == Dave Korn <dave.korn.cygwin@...> writes:

Dave> Ben Elliston wrote:
>> ::java::lang::String *
>> -java::net::VMURLConnection::guessContentTypeFromBuffer (jbyteArray bytes,
>> - jint valid)
>> +java::net::VMURLConnection::guessContentTypeFromBuffer (jbyteArray bytes __attribute__ ((unused)),
>> + jint valid __attribute__ ((unused)))

Dave> There's a #define MAYBE_UNUSED in include/jvm.h, as used in
Dave> java/lang/natClass.cc. But maybe jvm.h isn't available here?

It is ok to include jvm.h from any of the CNI code.

But, it is also ok to just use an unadorned __attribute__. We know this
code can only be compiled by g++.

Tom

Re: PATCH, libjava: silence more warnings

2009-12-01T10:49:07Z

Ben Elliston wrote:
> This patch silences a couple of more warnings in libjava:
>
> libjava/java/net/natVMURLConnection.cc:64:1: warning: unused parameter ‘bytes’
> libjava/java/net/natVMURLConnection.cc:64:1: warning: unused parameter ‘valid’
>
> Tested with a bootstrap on x86_64-linux. Okay for the trunk?

OK.

Andrew.

Re: PATCH, libjava: silence more warnings

2009-12-01T10:32:23Z

Ben Elliston wrote:

> ::java::lang::String *
> -java::net::VMURLConnection::guessContentTypeFromBuffer (jbyteArray bytes,
> - jint valid)
> +java::net::VMURLConnection::guessContentTypeFromBuffer (jbyteArray bytes __attribute__ ((unused)),
> + jint valid __attribute__ ((unused)))

There's a #define MAYBE_UNUSED in include/jvm.h, as used in
java/lang/natClass.cc. But maybe jvm.h isn't available here?

cheers,
DaveK

PATCH, libjava: silence more warnings

2009-12-01T10:22:11Z

This patch silences a couple of more warnings in libjava:

libjava/java/net/natVMURLConnection.cc:64:1: warning: unused parameter ‘bytes’
libjava/java/net/natVMURLConnection.cc:64:1: warning: unused parameter ‘valid’

Tested with a bootstrap on x86_64-linux. Okay for the trunk?

Ben

2009-12-02 Ben Elliston <bje@...>

* java/net/natVMURLConnection.cc (guessContentTypeFromBuffer):
Mark `bytes' and `valid' parameters as potentially unused.

Index: java/net/natVMURLConnection.cc
===================================================================
--- java/net/natVMURLConnection.cc (revision 154873)
+++ java/net/natVMURLConnection.cc (working copy)
@@ -61,8 +61,8 @@
}

::java::lang::String *
-java::net::VMURLConnection::guessContentTypeFromBuffer (jbyteArray bytes,
- jint valid)
+java::net::VMURLConnection::guessContentTypeFromBuffer (jbyteArray bytes __attribute__ ((unused)),
+ jint valid __attribute__ ((unused)))
{
#if defined (HAVE_MAGIC_T) && defined (HAVE_MAGIC_H) && defined (USE_LTDL)
const char *result;

Re: [patch] Fix oddity in personality routine

2009-12-01T09:24:29Z

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.

Re: [patch] Fix oddity in personality routine

2009-12-01T09:04:03Z

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?
Jack

Re: [patch] Fix oddity in personality routine

2009-12-01T01:29:36Z

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.

Re: [patch] Fix oddity in personality routine

2009-11-30T21:01:57Z

Andrew,
I have uploaded a bz2 archive of the walk from the
last _Unwind_RaiseException breakpoint before the crash
up to the crash to PR41991. The crash appears at...

_Jv_GetMethodLocal (klass=0x104a298c0, name=0x104af13a0, signature=0x104b1dfe0) at ../../../gcc-4.5-20091128/libjava/java/lang/natClass.cc:1633
1633 && _Jv_equalUtf8Consts (signature, klass->methods[i].signature))
(gdb)
_Jv_equalUtf8Consts (a=0x104b1dfe0, b=0x1048262c0) at ../../../gcc-4.5-20091128/libjava/prims.cc:209
209 if (a == b)
(gdb)
210 return true;
(gdb)
209 if (a == b)
(gdb)
211 if (a->hash != b->hash)
(gdb)
212 return false;
(gdb)
211 if (a->hash != b->hash)
(gdb)
214 if (b->length != len)
(gdb)
218 len = (len + 1) >> 1;
(gdb)
216 aptr = (const _Jv_ushort *)a->data;
(gdb)
217 bptr = (const _Jv_ushort *)b->data;
(gdb)
218 len = (len + 1) >> 1;
(gdb)
219 while (--len >= 0)
(gdb)
220 if (*aptr++ != *bptr++)
(gdb)
219 while (--len >= 0)
(gdb)
220 if (*aptr++ != *bptr++)
(gdb)
219 while (--len >= 0)
(gdb)
220 if (*aptr++ != *bptr++)
(gdb)
219 while (--len >= 0)
(gdb)
220 if (*aptr++ != *bptr++)
(gdb)
219 while (--len >= 0)
(gdb)
220 if (*aptr++ != *bptr++)
(gdb)
219 while (--len >= 0)
(gdb)
220 if (*aptr++ != *bptr++)
(gdb)
219 while (--len >= 0)
(gdb)
220 if (*aptr++ != *bptr++)
(gdb)
219 while (--len >= 0)
(gdb)
220 if (*aptr++ != *bptr++)
(gdb)
219 while (--len >= 0)
(gdb)
220 if (*aptr++ != *bptr++)
(gdb)
219 while (--len >= 0)
(gdb)
220 if (*aptr++ != *bptr++)
(gdb)
219 while (--len >= 0)
(gdb)
220 if (*aptr++ != *bptr++)
(gdb)
219 while (--len >= 0)
(gdb)
222 return true;
(gdb)
223 }
(gdb)
_Jv_GetMethodLocal (klass=0x104a298c0, name=0x104af13a0, signature=0x104b1dfe0) at ../../../gcc-4.5-20091128/libjava/java/lang/natClass.cc:1632
1632 if (_Jv_equalUtf8Consts (name, klass->methods[i].name)
(gdb)
1634 return &klass->methods[i];
(gdb)
1637 }
(gdb)
_Jv_LookupDeclaredMethod (klass=0x104a298c0, name=0x104af13a0, signature=0x104b1dfe0, declarer_result=0x0) at ../../../gcc-4.5-20091128/libjava/java/lang/natClass.cc:1648
1648 if (meth)
(gdb)
1650 if (declarer_result)
(gdb)
1657 }
(gdb)
gnu::java::lang::MainThread::call_main (this=0x104875dc0) at ../../../gcc-4.5-20091128/libjava/gnu/java/lang/natMainThread.cc:41
41 if (meth == NULL)
(gdb)
37 main_signature);
(gdb)
41 if (meth == NULL)
(gdb)
43 else if (! ::java::lang::reflect::Modifier::isStatic(meth->accflags))
(gdb)
_ZN4java4lang7reflect8Modifier8isStaticEJbi (mod=9) at Modifier.java:268
268 return (mod & STATIC) != 0;
(gdb)
_ZN4java4lang7reflect8Modifier8isStaticEJbi (mod=9) at Modifier.java:268
268 return (mod & STATIC) != 0;
(gdb)
0x0000000100994af0 in dyld_stub__Jv_InitClass () at RowSetEvent.java:51
51 RowSetEvent.java: No such file or directory.
in RowSetEvent.java
(gdb)
_Jv_InitClass (klass=0x10168ce40) at Class.h:740
740 if (__builtin_expect (klass->state == JV_STATE_DONE, true))
(gdb)
743 }
(gdb)
0x00000001004168bf in _ZN4java4lang7reflect8Modifier8isStaticEJbi (mod=9) at Modifier.java:268
268 return (mod & STATIC) != 0;
(gdb)
gnu::java::lang::MainThread::call_main (this=0x104875dc0) at ../../../gcc-4.5-20091128/libjava/gnu/java/lang/natMainThread.cc:44
44 msg = "`main' must be static";
(gdb)
43 else if (! ::java::lang::reflect::Modifier::isStatic(meth->accflags))
(gdb)
45 else if (! ::java::lang::reflect::Modifier::isPublic(meth->accflags))
(gdb)
_ZN4java4lang7reflect8Modifier8isPublicEJbi (mod=9) at Modifier.java:258
258 return (mod & PUBLIC) != 0;
(gdb)
_ZN4java4lang7reflect8Modifier8isPublicEJbi (mod=9) at Modifier.java:258
258 return (mod & PUBLIC) != 0;
(gdb)
0x0000000100994af0 in dyld_stub__Jv_InitClass () at RowSetEvent.java:51
51 RowSetEvent.java: No such file or directory.
in RowSetEvent.java
(gdb)
_Jv_InitClass (klass=0x10168ce40) at Class.h:740
740 if (__builtin_expect (klass->state == JV_STATE_DONE, true))
(gdb)
743 }
(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)

Let me know if you have any suggestions for debugging this further.
Jack