OpenJDK Zero PPC Build on OS X Leopard

[Kurt Miller]

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

Thanks,
-Kurt