OpenJDK Zero PPC Build on OS X Leopard
Kurt Miller
kurt at intricatesoftware.com
Wed Sep 14 13:42:20 PDT 2011
On Wednesday 14 September 2011 11:59:23 am Kurt Miller wrote:
> On Wednesday 14 September 2011 11:50:09 am Konstantin Tokarev wrote:
> >
> > 14.09.2011, 18:37, "Kurt Miller" <kurt at intricatesoftware.com>:
> > > On Wednesday 14 September 2011 04:24:27 am Konstantin Tokarev wrote:
> > >
> > >> 13.09.2011, 19:31, "Kurt Miller" <kurt at intricatesoftware.com>:
> > >>> On Tuesday 13 September 2011 11:18:15 am Konstantin Tokarev wrote:
> > >>>> 13.09.2011, 18:02, "Kurt Miller" :
> > >>>>> Ideally you could use my fastdebug w/atomic.diff build to generate the core and make it available to me (compressed). This would allow me to to do a more complete diagnostic on the crash.
> > >>>>>
> > >>>>> The build is here: http://www.intricatesoftware.com/OpenJDK/macppc/openjdk7-macppc-fcs-fd-atomic-2011-09-12.tar.bz2
> > >>>> Seems like your host is down
> > >>>>
> > >>>> http://www.downforeveryoneorjustme.com/www.intricatesoftware.com
> > >>> Thanks. I switched it to my backup ip. It is up again now.
> > >>>> I can send my core, though.
> > >>> It would be better to generate the core using my build so when I debug it here everything matches exactly.
> > >> Attached.
> > >
> > > Thank you. I downloaded it and checked it out with gdb. Unfortunately gdb can't unwind
> > > beyond the signal handler so I still can't see where the crash is comming from. :-(
> >
> > I'm afraid breakpoint with further single-stepping is needed. Could you give a hint about reasonable place?
>
> From the hotspot.log file it appeard to be crashing in the following function:
>
> jdk/src/share/native/java/lang/ClassLoader.c:316
> Java_java_lang_ClassLoader_00024NativeLibrary_load()
Yes it is crashing in this function. I was able to reproduce it in gdb on my G4 single processor.
Java_java_lang_ClassLoader_00024NativeLibrary_load gets called.
(gdb) p cname
$1 = 0x37853330 "/private/var/tmp/jna702102506712993250.tmp"
330 handle = JVM_LoadLibrary(cname);
returns a good handle and crashes on this line:
345 jniVersion = (*JNI_OnLoad)(jvm, NULL);
Program received signal EXC_BAD_ACCESS, Could not access memory.
Reason: KERN_PROTECTION_FAILURE at address: 0x00000000
0x00000000 in ?? ()
The library it loaded is a universal binary:
kurt-millers-powerbook-g4-56:jdk truk$ file /private/var/tmp/jna702102506712993250.tmp
/private/var/tmp/jna702102506712993250.tmp: Mach-O universal binary with 3 architectures
/private/var/tmp/jna702102506712993250.tmp (for architecture ppc7400): Mach-O dynamically linked shared library ppc
/private/var/tmp/jna702102506712993250.tmp (for architecture i386): Mach-O dynamically linked shared library i386
/private/var/tmp/jna702102506712993250.tmp (for architecture x86_64): Mach-O 64-bit dynamically linked shared library x86_64
This file comes from netbeans:
jar -xf netbeans/platform/modules/ext/jna-3.2.7.jar com/sun/jna/darwin/libjnidispatch.jnilib
kurt-millers-powerbook-g4-56:netbeans truk$ md5 com/sun/jna/darwin/libjnidispatch.jnilib
MD5 (com/sun/jna/darwin/libjnidispatch.jnilib) = 9dc88187671967d15c7ab13600e18b96
kurt-millers-powerbook-g4-56:netbeans truk$ md5 /private/var/tmp/jna702102506712993250.tmp
MD5 (/private/var/tmp/jna702102506712993250.tmp) = 9dc88187671967d15c7ab13600e18b96
The exact spot where it crashes is JNI_OnLoad+72 in the copy of com/sun/jna/darwin/libjnidispatch.jnilib
from netbeans/platform/modules/ext/jna-3.2.7.jar.
See below for registers and disassembly:
(gdb) info reg
r0 0x0 0
r1 0xf1214350 4045488976
r2 0x17fc9b4 25151924
r3 0x17d9f68 25010024
r4 0xf1214388 4045489032
r5 0x10004 65540
r6 0xffffffff 4294967295
r7 0x0 0
r8 0x0 0
r9 0xf1214464 4045489252
r10 0x10016cc 16783052
r11 0x17e9750 25073488
r12 0x0 0
r13 0x0 0
r14 0x0 0
r15 0x0 0
r16 0x0 0
r17 0x0 0
r18 0x0 0
r19 0x0 0
r20 0x0 0
r21 0x0 0
r22 0x0 0
r23 0x0 0
r24 0x0 0
r25 0xa0b16e44 2695982660
r26 0x17d9f68 25010024
r27 0x15d34d8 22885592
r28 0xf12145d0 4045489616
r29 0xf1214388 4045489032
r30 0xf1214350 4045488976
r31 0x36fe44e8 922633448
pc 0x0 0
ps 0xd030 53296
cr 0x22000224 570425892
lr 0x36fe451c 922633500
ctr 0x0 0
xer 0x0 0
mq 0x0 0
fpscr 0x82004000 2181054464
vscr 0x10000 65536
vrsave 0x0 0
(gdb) x/20i 0x36fe44d0
0x36fe44d0 <JNI_OnLoad>: mfcr r2
0x36fe44d4 <JNI_OnLoad+4>: mflr r0
0x36fe44d8 <JNI_OnLoad+8>: stmw r13,-76(r1)
0x36fe44dc <JNI_OnLoad+12>: lis r5,1
0x36fe44e0 <JNI_OnLoad+16>: mr r26,r3
0x36fe44e4 <JNI_OnLoad+20>: bcl- 20,4*cr7+so,0x36fe44e8 <JNI_OnLoad+24>
0x36fe44e8 <JNI_OnLoad+24>: stw r0,8(r1)
0x36fe44ec <JNI_OnLoad+28>: ori r5,r5,4
0x36fe44f0 <JNI_OnLoad+32>: mflr r31
0x36fe44f4 <JNI_OnLoad+36>: stw r2,4(r1)
0x36fe44f8 <JNI_OnLoad+40>: stwu r1,-192(r1)
0x36fe44fc <JNI_OnLoad+44>: lwz r2,0(r3)
0x36fe4500 <JNI_OnLoad+48>: mr r30,r1
0x36fe4504 <JNI_OnLoad+52>: addi r29,r30,56
0x36fe4508 <JNI_OnLoad+56>: lwz r0,40(r2)
0x36fe450c <JNI_OnLoad+60>: mr r4,r29
0x36fe4510 <JNI_OnLoad+64>: mtctr r0
0x36fe4514 <JNI_OnLoad+68>: mr r12,r0
0x36fe4518 <JNI_OnLoad+72>: bctrl
At this point I'm unsure why we're failing. Anyone know PowerPC assemby well enough
to determine why the ctr register is 0x0?
Regards,
-Kurt
More information about the bsd-port-dev
mailing list