java/1912: Segfault when handling segfault = infinite recursion

[paul at dawa dot demon dot co dot uk]

>Number:         1912
>Category:       java
>Synopsis:       Segfault when handling segfault = infinite recursion
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    unassigned
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Thu Feb 08 07:46:01 PST 2001
>Closed-Date:
>Last-Modified:
>Originator:     paul@dawa.demon.co.uk
>Release:        gcc version 2.97 20010208 (experimental)
>Organization:
>Environment:
RedHat Linux 7.0 x86
>Description:
JDMK's mibgen segfaulted due to a null java class pointer (this
is itself probably a gcj bug, since the same code works
in both Sun's and IBM's JDK). It the went into infinite recurion
as FindClassInCache segfaulted during the handling of the segfault.

The problem seems to be cause by an exception table entry
with a match_info field which is -1 which caused FindClass
to get called with a value of 0xfffffffe for "name".

Program received signal SIGSEGV, Segmentation fault.
_Jv_FindClassInCache(_Jv_Utf8Const*, java::lang::ClassLoader*) (
    name=0xfffffffe, loader=0x0)
    at ../../../gcc/libjava/java/lang/natClassLoader.cc:337
337	  jint hash = HASH_UTF (name);

(gdb) bt
#0  _Jv_FindClassInCache(_Jv_Utf8Const*, java::lang::ClassLoader*) (
    name=0xfffffffe, loader=0x0)
    at ../../../gcc/libjava/java/lang/natClassLoader.cc:337
#1  0x4019afc1 in _Jv_FindClass(_Jv_Utf8Const*, java::lang::ClassLoader*) (
    name=0xfffffffe, loader=0x0)
    at ../../../gcc/libjava/java/lang/natClassLoader.cc:460
#2  0x4018966a in _Jv_type_matcher (info=0x83dcde8, match_info=0xffffffff, 
    exception_table=0x8392d64) at ../../../gcc/libjava/exception.cc:62
#3  0x082531a1 in find_exception_handler (pc=0x81e8a2b, table=0x8392d64, 
    eh_info=0x83dcde8, rethrow=0, cleanup=0xbfffeb3c)
#4  0x082536fa in throw_helper (eh=0x8398f60, pc=0x81e8a2c, 
    my_udata=0xbfffedb0, offset_p=0xbfffedac)
#5  0x082537ea in __throw ()
#6  0x401897ba in _Jv_Throw (value=0x83b1fe0)
    at ../../../gcc/libjava/exception.cc:160
#7  0x081e8a2d in com.sun.jdmk.tools.mibgen.Parser.Mibs(com.sun.jdmk.tools.mibgen.ModulesHandler) (this=0x8435bd0, ARG_1=0x8413018)
    at com/sun/jdmk/tools/mibgen/Parser.java:49
#8  0x0819456f in com.sun.jdmk.tools.MibGen.doCompile() (this=0x83f2268)
    at com/sun/jdmk/tools/MibGen.java:265
#9  0x08195e5b in com.sun.jdmk.tools.MibGen.startCompile(java.lang.String[]) (
    this=0x83f2268, ARG_1=0x83d1f00) at com/sun/jdmk/tools/MibGen.java:499
#10 0x0819404f in com.sun.jdmk.tools.MibGen.compile(java.lang.String[]) (
    ARG_1=0x83d1f00) at com/sun/jdmk/tools/MibGen.java:484
#11 0x0819500b in com.sun.jdmk.tools.MibGen.main(java.lang.String[]) (
    ARG_1=0x83d1f00) at com/sun/jdmk/tools/MibGen.java:459
#12 0x401964db in gnu::gcj::runtime::FirstThread::run() (this=0x83b4ed0)
    at ../../../gcc/libjava/gnu/gcj/runtime/natFirstThread.cc:146
#13 0x401a0bcb in java::lang::Thread::run_(java::lang::Object*) (obj=0x83b4ed0)
    at ../../../gcc/libjava/java/lang/natThread.cc:276
#14 0x402bc35a in _Jv_ThreadStart(java::lang::Thread*, int*, void (*)(java::lang::Thread*)) (thread=0x83b4ed0, 
    meth=0x401a0a20 <java::lang::Thread::run_(java::lang::Object*)>)
    at ../../../gcc/libjava/no-threads.cc:28
#15 0x401a0cdf in java::lang::Thread::start() (this=0x83b4ed0)
    at ../../../gcc/libjava/java/lang/natThread.cc:307
#16 0x40180ff2 in JvRunMain (klass=0x82ca7a0, argc=37, argv=0xbffff1c4)
    at ../../../gcc/libjava/prims.cc:848
#17 0x082525e3 in main (argc=37, argv=0xbffff1c4) at /tmp/cce3lA2gmain.i:11
#18 0x404bbe51 in __libc_start_main (main=0x82525c0 <main>, argc=37, 
    ubp_av=0xbffff1c4, init=0x8053e68 <_init>, fini=0x8254d5c <_fini>, 
    rtld_fini=0x4000e264 <_dl_fini>, stack_end=0xbffff1bc)
    at ../sysdeps/generic/libc-start.c:111
>How-To-Repeat:
Difficult - I can't reproduce this easily in a small
test case :(
>Fix:

>Release-Note:
>Audit-Trail:
>Unformatted: