In _Jv_ResolvePoolEntry, if no method is found in the JV_CONSTANT_Methodref/JV_CONSTANT_InterfaceMethodref case, _Jv_DetermineVTableIndex may be called with found_class == NULL, causing a NullPointerException when _Jv_DetermineVTableIndex calls getSuperclass(). Release: 3.3 20020820 (experimental) Environment: System: Linux churchill 2.4.3-12 #1 Fri Jun 8 15:05:56 EDT 2001 i686 unknown Architecture: i686 host: i686-pc-linux-gnu build: i686-pc-linux-gnu target: i686-pc-linux-gnu configured with: ../gcc/configure --prefix=/home/user/jmr/app/gcc --enable-langs=c++,java --enable-shared --enable-threads=posix --with-as=/home/user/jmr/app/binutils/bin/as --with-ld=/home/user/jmr/app/binutils/bin/ld How-To-Repeat: I haven't reduced it to a small test case yet, but it is clear that some error other than NullPointerException should be reported.
Fix: I'm not sure about this, but it does get rid of the NullPointerException, and since the_method is not modified by the code I moved, perhaps the author intended the the_method == 0 check to go first. Index: resolve.cc =================================================================== RCS file: /cvsroot/gcc/gcc/libjava/resolve.cc,v retrieving revision 1.29 diff -c -r1.29 resolve.cc *** resolve.cc 20 Jun 2002 15:10:49 -0000 1.29 --- resolve.cc 24 Aug 2002 06:07:08 -0000 *************** *** 300,315 **** // with either loader should produce the same result, // i.e., exactly the same jclass object. JVMS 5.4.3.3 - if (pool->tags[index] == JV_CONSTANT_InterfaceMethodref) - vtable_index = -1; - else - vtable_index = _Jv_DetermineVTableIndex - (found_class, method_name, method_signature); - - if (vtable_index == METHOD_NOT_THERE) - throw_incompatible_class_change_error - (JvNewStringLatin1 ("method not found")); - if (the_method == 0) { jstring msg = JvNewStringLatin1 ("method "); --- 300,305 ---- *************** *** 320,325 **** --- 310,325 ---- throw new java::lang::NoSuchMethodError (msg); } + if (pool->tags[index] == JV_CONSTANT_InterfaceMethodref) + vtable_index = -1; + else + vtable_index = _Jv_DetermineVTableIndex + (found_class, method_name, method_signature); + + if (vtable_index == METHOD_NOT_THERE) + throw_incompatible_class_change_error + (JvNewStringLatin1 ("method not found")); + pool->data[index].rmethod = _Jv_BuildResolvedMethod(the_method, found_class,
Responsible-Changed-From-To: unassigned->tromey Responsible-Changed-Why: I'm handling the administrivia
State-Changed-From-To: open->closed State-Changed-Why: Thanks. I agree your patch is correct. I'm checking it in.
From: tromey@gcc.gnu.org To: gcc-gnats@gcc.gnu.org Cc: Subject: libgcj/7709 Date: 25 Sep 2002 21:02:33 -0000 CVSROOT: /cvs/gcc Module name: gcc Changes by: tromey@gcc.gnu.org 2002-09-25 14:02:33 Modified files: libjava : ChangeLog resolve.cc Log message: 2002-09-25 Jesse Rosenstock <jmr@ugcs.caltech.edu> * resolve.cc (_Jv_ResolvePoolEntry) [end_of_method_search]: Check to see if `the_method == 0' before looking up vtable index. Fixes PR libgcj/7709. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libjava/ChangeLog.diff?cvsroot=gcc&r1=1.1456&r2=1.1457 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libjava/resolve.cc.diff?cvsroot=gcc&r1=1.31&r2=1.32