Patch in libjava/exception.cc

[Erwin Bolwidt]

Hello list,

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
__gcj_personality_v0

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))

with

exception.cc:348: if (catch_type != NULL && _Jv_IsInstanceOf (xh->value,
catch_type))

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,
catch_type))

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.


Best regards,
  Erwin Bolwidt