I would like some help debugging a SIGSEGV on cygwin.
uname -a: CYGWIN_NT-5.0 A6 1.3.10(0.51/3/2) 2002-02-25 11:14 i686 unknown Kaffe from CVS Configure options: --without-x --with-staticbin --with-staticlib --with-staticvm --with-engine=intrp Klasses.jar rebuilt with jikes 1.13 'make check' fails with (amongst others) test/regression/Alias.fail: java.lang.NullPointerException at kaffe.io.ObjectStreamClassImpl.outputClassFields(ObjectStreamClassImpl.java:native) at kaffe.io.ObjectStreamClassImpl.defaultWriteObject(ObjectStreamClassImpl.java:342) at kaffe.io.ObjectStreamClassImpl.putObjectWithoutSuper(ObjectStreamClassImpl.java:239) at kaffe.io.ObjectStreamClassImpl.putObject(ObjectStreamClassImpl.java:217) at kaffe.io.ObjectOutputStreamImpl.writeObject(ObjectOutputStreamImpl.java:154) at java.io.ObjectOutputStream.writeObject(ObjectOutputStream.java:151) at kaffe.io.ObjectStreamClassImpl.outputClassFields(ObjectStreamClassImpl.java:native) at kaffe.io.ObjectStreamClassImpl.defaultWriteObject(ObjectStreamClassImpl.java:342) at kaffe.io.ObjectStreamClassImpl.putObjectWithoutSuper(ObjectStreamClassImpl.java:239) at kaffe.io.ObjectStreamClassImpl.putObject(ObjectStreamClassImpl.java:217) at kaffe.io.ObjectOutputStreamImpl.writeObject(ObjectOutputStreamImpl.java:154) at java.io.ObjectOutputStream.writeObject(ObjectOutputStream.java:151) at Alias.main(Alias.java:58) The SEGV occurs in file libraries/clib/native/ObjectStreamClassImpl.c func newSerialObject line 785 n = CLASS_NMETHODS(clazz); because clazz == 0 If I go up a stack frame to file libraries/clib/native/ObjectStreamClassImpl.c func kaffe_io_ObjectStreamClassImpl_outputClassFields line 211 obj = newSerialObject(unhand(cls)->iclazz, obj); I can print the 'obj' (gdb) pobject obj int x = 0x1 int y = 0x1 (gdb) pobject cls (unresolved Ljava/lang/Class;) int method = 0x2 long serialVersionUID = icky kaffe/io/ObjectStreamClassImpl superstream = 0x0 java/lang/Class iclazz = 0x0 (unresolved [Lkaffe/util/Ptr;) (I'm still learning the handy gdb macros.) Above this on the stack is a long sequence of runVirtualMachine virtualMachine What's the best way to attack this? If I build Kaffe as an all-static interpreter on another OS I should be able to compare them fairly closely, right?