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" <k...@intricatesoftware.com>: > > > On Wednesday 14 September 2011 04:24:27 am Konstantin Tokarev wrote: > > > > > >> 13.09.2011, 19:31, "Kurt Miller" <k...@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
