From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 422 invoked by alias); 23 Dec 2009 13:34:52 -0000 Received: (qmail 414 invoked by uid 22791); 23 Dec 2009 13:34:51 -0000 X-SWARE-Spam-Status: No, hits=-1.4 required=5.0 tests=AWL,BAYES_00,SARE_MSGID_LONG40,WEIRD_PORT X-Spam-Check-By: sourceware.org Received: from mail-pw0-f57.google.com (HELO mail-pw0-f57.google.com) (209.85.160.57) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Wed, 23 Dec 2009 13:34:46 +0000 Received: by pwi12 with SMTP id 12so4660934pwi.16 for ; Wed, 23 Dec 2009 05:34:45 -0800 (PST) MIME-Version: 1.0 Received: by 10.141.130.15 with SMTP id h15mr4481992rvn.121.1261575285156; Wed, 23 Dec 2009 05:34:45 -0800 (PST) In-Reply-To: <4B31F521.1010404@redhat.com> References: <4B31F521.1010404@redhat.com> Date: Wed, 23 Dec 2009 13:34:00 -0000 Message-ID: Subject: Re: problem with class accessiblity check in invoke (natMethod.cc) From: Erik Groeneveld To: Andrew Haley Cc: java Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-IsSubscribed: yes Mailing-List: contact java-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: java-owner@gcc.gnu.org X-SW-Source: 2009-12/txt/msg00063.txt.bz2 Hello Andrew, Thanks for your quick reply. We include code below. On Wed, Dec 23, 2009 at 11:46, Andrew Haley wrote: > On 12/23/2009 10:38 AM, Erik Groeneveld wrote: > [...] >> =C2=A0 =C2=A0 =C2=A0 else >> =C2=A0 =C2=A0 =C2=A0 // Method is public, check to see if class is acces= sible. >> =C2=A0 =C2=A0 =C2=A0 { >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 jint flags =3D (declaringClass->accflags >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 & (Modifier::PUBLIC >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0| Modifier::PROTECTED >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0| Modifier::PRIVATE)); >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 if (flags =3D=3D 0) // i.e. class is package= private >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 { >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Class *caller =3D _Jv_StackTra= ce::GetCallingClass (&Method::class$); >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 if (! _Jv_ClassNameSamePackage= (caller->name, >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 declaringClass->name)) >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 throw new IllegalAccess= Exception; >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 } >> =C2=A0 =C2=A0 =C2=A0 } >> =C2=A0 =C2=A0 } >> [...] >> 1. The systems segfaults on the caller->name because there is no calling= class. > > How can there be no calling class? Because we call it from C++ not from Java. We forgot to mention that. >> 2. We believe class accessibility is not relevant here: there is no >> reason why a Method object with public access should not be invokable, >> or is there? [...] > > Yes, but can you send a test case before we go any further? =C2=A0Then at= least > we'll all know what you're talking about. The following code demonstrates the problem. #include #include #include #include #include int main(int argc, char* argv[]) { JvCreateJavaVM(NULL); JvAttachCurrentThread(NULL, NULL); java::util::ArrayList* l =3D new java::util::ArrayList(); java::util::Iterator* i =3D l->iterator(); java::lang::reflect::Method* m =3D i->getClass()->getDeclaredMethod( JvNewStringUTF("hasNext"), NULL); printf("calling invoke, it'll dump core in natMethod.cc line 194\n"); m->invoke(i, NULL); return 0; } $gcc problem.cpp -lgcj $./a.out calling invoke Aborted (core dumped) $gdb -core core a.out (gdb) where #0 0x00002adf9252bed5 in raise () from /lib/libc.so.6 #1 0x00002adf9252d3f3 in abort () from /lib/libc.so.6 #2 0x00002adf90bdeed8 in _Jv_Throw (value=3D0x2adf932cd370) at ../../../src/libjava/exception.cc:128 #3 0x00002adf90bd2a2a in _Jv_catch_segv (_p=3D) at ../../../src/libjava/prims.cc:184 #4 #5 0x00002adf90c217d3 in java::lang::reflect::Method::invoke (this=3D0x2adf932d1c80, obj=3D0x2adf93ba6e40, args=3D0x0) at ../../../src/libjava/java/lang/reflect/natMethod.cc:194 #6 0x0000000000400a5c in main () The top of the stack is from the NULL-pointer catching signal handler we believe, so #5 and #6 are the relevant ones. The point is that we believe that the scenario in the C++ code is valid, both from Java and from C++, and we do not see the reasons for the additional check that has been added to the invoke() method. Erik Jurjan-Paul