OpenJDK Zero PPC Build on OS X Leopard

[Kurt Miller]

On Tuesday 13 September 2011 02:42:18 am Konstantin Tokarev wrote:
> 
> 12.09.2011, 04:44, "Kurt Miller" <kurt at intricatesoftware.com>:
> > On 9/10/11 10:18 AM, Konstantin Tokarev wrote:
> >
> >>  09.09.2011, 21:55, "Kurt Miller"<kurt at intricatesoftware.com>:
> >>>  The February builds also included some atomic operations diffs I was
> >>>  working on to fix SMP. I left them out of this build because I wanted to
> >>>  release a build that exactly matched the committed bsd-port.
> >>>
> >>>  Please try a build with the attached diff to see if that helps corrects this problem.
> >>  Yes, it helps. Simple applications are running fine now.
> >
> > Thanks, that's good. Since we're still having problems, I'm not sure it
> > is 100% correct yet.
> >
> >>  I've tried to launch Netbeans again. Now it went further, but that JVM crashed (log is attached):
> >>
> >>  #  Internal Error (/Volumes/Development/src/java/bsd-port-hg/hotspot/src/os_cpu/bsd_zero/vm/os_bsd_zero.cpp:258), pid=33861, tid=4048646144
> >
> > This is the line where fatal() is called in the signal handler, not the
> > line that caused the segfault.
> >
> >>  Crashed Thread:  12
> >>
> >>  Thread 12 Crashed:
> >>  0   libSystem.B.dylib              0x9526a2ac __semwait_signal_nocancel + 8
> >>  1   libSystem.B.dylib              0x95269d78 nanosleep$NOCANCEL$UNIX2003 + 176
> >>  2   libSystem.B.dylib              0x95262fdc usleep$NOCANCEL$UNIX2003 + 68
> >>  3   libSystem.B.dylib              0x9527cc00 abort + 92
> >>  4   libjvm.dylib                   0x0158c004 os::abort(bool) + 340
> >>  5   libjvm.dylib                   0x016d8eac VMError::report_and_die() + 2748
> >>  6   libjvm.dylib                   0x011c6da0 report_fatal(char const*, int, char const*) + 112
> >>  7   libjvm.dylib                   0x01590700 JVM_handle_bsd_signal + 1088
> >
> > The above stack trace unwinds only to the signal handler, so I can't see
> > what code caused the segfault.
> >
> >  From the log file:
> >
> > Current thread (0x00896618):  JavaThread "main" [_thread_in_native,
> > id=-246321152, stack(0xf1317000,0xf1517000)]
> >
> > Stack: [0xf1317000,0xf1517000],  sp=0xf1414938,  free space=1014k
> > Java frames:
> >   0xf15151a0: unboxed parameter[2]  = 0xf1515204
> >   0xf15151a4: unboxed parameter[1]  = 0xf1515208
> >   0xf15151a8: parameter[0] (JNIEnv) = 0xf1415a4c
> >   0xf15151ac: parameter[1] (this)   = 0xf15151a4
> >   0xf15151b0: parameter[2]          = 0xf15151a0
> >   0xf15151b4: (vtable for istate)   = 0x10735a1f
> >   0xf15151b8: istate->_thread       = 0x00896618
> >   0xf15151bc: istate->_bcp          = 0x00000000
> >   0xf15151c0: istate->_locals       = 0xf1515208
> >   0xf15151c4: istate->_constants    = 0x10735f00
> >   0xf15151c8: istate->_method       =
> > java.lang.ClassLoader$NativeLibrary.load(Ljava/lang/String;)V
> >
> > The above appears to be calling into native function
> > jdk/src/share/native/java/lang/ClassLoader.c:316
> > Java_java_lang_ClassLoader_00024NativeLibrary_load().
> >
> > Do you know how to use gdb? If so, can you capture the segfault in gdb
> > to see where it is crashing? If not, please reproduce with core files
> > enabled and send me the output of the following commands:
> >
> > gdb <path to>/java <path to core file>
> > bt
> 
> Though I know gdb, second way is more handy because Netbeans is launched by shell script :)
> 
> (gdb) bt
> #0  0x95166a88 in nanosleep$UNIX2003 ()
> #1  0x00005754 in ContinueInNewThread0 (continuation=0, stack_size=0, args=0xf03) at ../../../src/solaris/bin/java_md.c:1495
> #2  0x000052f0 in JLI_Launch (argc=5, argv=0x100338, jargc=<value temporarily unavailable, due to optimizations>, jargv=<value temporarily unavailable, due to optimizations>, appclassc=1, appclassv=0x0, fullversion=<value temporarily unavailable, due to optimizations>, dotversion=<value temporarily unavailable, due to optimizations>, pname=0x16ce4 "java", lname=0x16cec "openjdk", javaargs=<value temporarily unavailable, due to optimizations>, cpwildcard=<value temporarily unavailable, due to optimizations>, javaw=<value temporarily unavailable, due to optimizations>, ergo=0) at ../../../src/share/bin/java.c:1913
> #3  0x0000d3b4 in main (argc=<value temporarily unavailable, due to optimizations>, argv=<value temporarily unavailable, due to optimizations>) at ../../../../src/share/bin/main.c:106
> 
> 
> Probably the wrong thing is that it went to solaris source code somehow (???).

On the jdk/src side it is normal for bsd support to use the solaris sub-dirs (similar to what linux support does).

> I could try to debug further, but I don't have more time right now.

No Problem. gdb didn't switch to the crashing thread above so we're looking at the main thread that didn't crash. Instead could you provide the output of 'thread apply all bt'?

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

Regards,
-Kurt