[3.3] classloader failure

Mon Mar 17 18:35:00 GMT 2003

Hi,
On Mon, 2003年03月17日 at 15:45, Jeff Sturm wrote:
> Here's a strange failure I first noticed last weekend:
>> Program received signal SIGSEGV, Segmentation fault.
> [Switching to Thread 1024 (LWP 22174)]
> 0x403b8d98 in _Jv_FindClass(_Jv_Utf8Const*, java::lang::ClassLoader*) (
> name=0x8831b18, loader=0x0)
> at ../../../libjava/java/lang/natClassLoader.cc:488
> 488 klass = sys->loadClass (sname, false);
>> It turns out that "sys" is null, all right. This is trying to load
> gnu.java.locale.Calendar_en_US, as a consequence of:
>> #9 0x404c8765 in java.util.zip.ZipEntry.getCalendar() ()
> at ../../../libjava/java/util/zip/ZipEntry.java:218

Ugh. That shouldn't happen. Could you post the complete stacktrace.
getCalendar() should only be called when ZipEntry.setTime() is called
which the bootstrap classes shouldn't do.
> The singleton VMClassLoader isn't ready because VMClassLoader is still
> initializing:
>> #24 0x40435587 in gnu.gcj.runtime.VMClassLoader.<clinit>() ()
> at ../../../libjava/gnu/gcj/runtime/VMClassLoader.java:71
>> My CLASSPATH contains jar files. Exploding the jars into a single
> directory and fixing CLASSPATH avoids the problem.
>> Anybody else seeing this? Any suggestions on how to fix it?

The correct fix would be to really make VMClassLoader the bootstrap
classloader that only loads the native compiled classes (libgcj.so).
Currently it uses a URLClassLoader and the interpreter to fallback to
the jar/zip/class files on the classpath. We actually should create a
real Application/SystemClassLoader that has the VMClassLoader (or maybe
null) as its parent. I believe the Classpath setup gets this right.
(Note that the libgcj setup is a bit confusing since it has two
VMClassLoader classes, the above one and one in java.lang.)
Cheers,
Mark