OpenJDK Zero PPC Build on OS X Leopard
Konstantin Tokarev
annulen at yandex.ru
Thu Sep 15 02:43:02 PDT 2011
15.09.2011, 00:42, "Kurt Miller" <kurt at intricatesoftware.com>:
> 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?
I'm n00b here (but I promise I'll learn it :). However, I propose the next plan:
1. Check if stand-alone JNA works with our JDK
2. Build JNA with full debug information
3. If on step (1) some test crashed, debug it, otherwise replace JNA jar in NetBeans and debug whole thing.
--
Regards,
Konstantin
More information about the bsd-port-dev
mailing list