Re: CNI and interface methods

[Andrew Haley <aph at redhat dot com>]

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 
> <http://www.cl.cam.ac.uk/~srk31/private/cake-snapshot-20090402.tar.bz2> 
> 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.