Patch in libjava/exception.cc
Fri May 25 03:23:00 GMT 2001
When trying to run an app compiled with gcc, it would consistently hand on
some input files, and then dump core after a long while.
With ltrace the picture was: an exception was being thrown with _Jv_Throw,
then a couple of __gcj_personality_v0 calls would occur, then a SIGSEGV,
then a fillInStackTrace. After that it would repeat from __gcj_personality
to the SEGV to the fillInStackTrace.
While inspecting the error with gdb, I found that the segmentation fauls
occurred in libjava/java/lang/Class.h in jclass->isArray, which was being
called indirectly from libjava/exception.cc at line 348 in the function
It would pass a NULL pointer for the catch_type to the _Jv_IsInstanceOf
method, which is clearly not what _Jv_IsInstanceOf is expecting.
The variable catch_type is NULL because _Jv_FindClass returned NULL. I
don't know what that means; if this is an error in _Jv_FindClass or
whether the return value of _Jv_FindClass should be checked. I wonder what
a NULL jclass while unwinding the stack means; could this be a catch for
all types of exceptions, to implement the finally construct?
I have a fix which works for me, but I'm not sure why it works so I hope
someone more knowledgable can have a look.
The fix is to replace:
exception.cc:348: if (_Jv_IsInstanceOf (xh->value, catch_type))
exception.cc:348: if (catch_type != NULL && _Jv_IsInstanceOf (xh->value,
This makes everything work and causes no further errors in my app or in
the gcj libraries.
But as far as I am concerned it could just as well have been replaced with
exception.cc:348: if (catch_type == NULL || _Jv_IsInstanceOf (xh->value,
I didn't test that, but if a NULL catch_type means a 'catch-all', then
this would be the correct fix.
Btw I'm running on a Pentium III with a 2.4.4 kernel and a gcc 3.0 branch
that was last updated at wednesday, midnight GMT.
More information about the Java