From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 26894 invoked by alias); 3 Apr 2009 08:37:51 -0000 Received: (qmail 26886 invoked by uid 22791); 3 Apr 2009 08:37:51 -0000 X-SWARE-Spam-Status: No, hits=-0.8 required=5.0 tests=AWL,BAYES_50,J_CHICKENPOX_65,SPF_HELO_PASS,SPF_PASS X-Spam-Check-By: sourceware.org Received: from mx2.redhat.com (HELO mx2.redhat.com) (66.187.237.31) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Fri, 03 Apr 2009 08:37:45 +0000 Received: from int-mx2.corp.redhat.com (int-mx2.corp.redhat.com [172.16.27.26]) by mx2.redhat.com (8.13.8/8.13.8) with ESMTP id n338biCf016104; Fri, 3 Apr 2009 04:37:44 -0400 Received: from ns3.rdu.redhat.com (ns3.rdu.redhat.com [10.11.255.199]) by int-mx2.corp.redhat.com (8.13.1/8.13.1) with ESMTP id n338biu0003097; Fri, 3 Apr 2009 04:37:44 -0400 Received: from zebedee.pink (vpn-12-137.rdu.redhat.com [10.11.12.137]) by ns3.rdu.redhat.com (8.13.8/8.13.8) with ESMTP id n338bgJ4001650; Fri, 3 Apr 2009 04:37:42 -0400 Message-ID: <49D5CAD4.8040700@redhat.com> Date: Fri, 03 Apr 2009 08:37:00 -0000 From: Andrew Haley User-Agent: Thunderbird 2.0.0.17 (X11/20081009) MIME-Version: 1.0 To: Stephen Kell CC: java@gcc.gnu.org Subject: Re: CNI and interface methods References: <20090402193827.GD4939@font.cl.cam.ac.uk> In-Reply-To: <20090402193827.GD4939@font.cl.cam.ac.uk> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit 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-04/txt/msg00004.txt.bz2 Stephen Kell wrote: > I'm using CNI for the first time and have hit a query. What exactly is > and isn't supposed to work when invoking interface methods through > *object* references (from C++, so I mean pointers), and passing these > references around? > > The CNI chapter in the gcj manual says a lot about interface references, > but not about the case of using object references where that object's > class implements one or more interfaces. One thing that would appear to > be worth mentioning is that clearly, passing them to methods wanting an > interface reference won't compile without some sort of cast, since the > gcjh-generated headers don't encode the subtyping relationship between > interfaces and their implementing classes. I'm guessing a simple static > cast isn't the right thing to do though, because I'm getting segfaults > when I try. Right. To put it simply, we have never got around to implementing Java interface calls in CNI. It wouldn't be enormously difficult, but it needs some way to tell the C++ compiler about interface calls. We could have implemented Java interfaces via C++ multiple inheritance but we didn't, so we would need to invent some sort of notation to express the idea of an interface to the C++ compiler. > Specifically, I'm CNI-calling from C++ to Java code which, in turn, > makes a call through an interface reference that I previously passed in > to the Java object's constructor (i.e. I passed in an *object* > reference, again from the C++ code, which required a cast as I just > described). I get a segfault during the calling sequence of the > interface call made by the Java code. The fault occurs just before the > call to _Jv_LookupInterfaceMethodIdx. > > (This is all on a fresh build of vanilla gcc 4.3.3, on i686 Linux, by > the way.) > > Program received signal SIGSEGV, Segmentation fault. > [Switching to Thread 0xb7f5e8f0 (LWP 26704)] > 0x080828ad in cakeJavaParser.toplevel()cakeJavaParser$toplevel_return () > at cakeJavaParser.java:145 > 145 retval.start = input.LT(1); > Current language: auto; currently java > (gdb) bt > #0 0x080828ad in > cakeJavaParser.toplevel()cakeJavaParser$toplevel_return () > at cakeJavaParser.java:145 > #1 0x0805a4e2 in cake::request::process (this=@bffd0c18) at cake.cpp:33 > #2 0x0805a7da in main (argc=2, argv=@bffd0cd4) at main.cpp:52 > > (Possibly significant: in earlier test runs, with a previous build of my > code, I was getting the segfault *during* the call to > _Jv_LookupInterfaceMethodIdx, with iface->ioffsets being null when it > probably shouldn't. I can't reproduce that now for some reason.) > > The extent of my CNI code is > > JvCreateJavaVM(NULL); > JvAttachCurrentThread(NULL, NULL); > JvInitClass(&java::lang::System::class$); > > and shortly afterwards > > org::antlr::runtime::ANTLRInputStream *stream = new org::antlr::runtime::ANTLRInputStream(in_file); > cakeJavaLexer *lexer = new cakeJavaLexer((org::antlr::runtime::CharStream*) stream); > org::antlr::runtime::CommonTokenStream *tokenStream = new org::antlr::runtime::CommonTokenStream((org::antlr::runtime::TokenSource*) lexer); > cakeJavaParser *parser = new cakeJavaParser((org::antlr::runtime::TokenStream*) tokenStream); > parser->toplevel(); > > where the last statement triggers the segfault. The toplevel() method is > Java code; it immediately calls a method on lexer (the object I passed > earlier) and it's this call whose dispatch fails. > > Should this code work? I thought about class initialization, but having > read the docs, it wouldn't appear that I need to add any JvInitClass > calls manually in this case. > > There's a tarball at > > which should be sufficient to reproduce the above (just do 'make test'), > unless I've forgotten to include something. Let me know if there's any > more details that would be useful. > > Thanks for reading! Any answers or ideas appreciated, It's because you're using -Bsymbolic but not -fpic. -Bsymbolic is dangerous, and any use of it without PIC means instant death. So, compile everything PIC, even the executable, and you'll be fine. That worked for me on your example. Andrew.