public inbox for java@gcc.gnu.org
 help / color / mirror / Atom feed
From: Stephen Kell <srk31@srcf.ucam.org>
To: java@gcc.gnu.org
Subject: CNI and interface methods
Date: Thu, 02 Apr 2009 19:38:00 -0000	[thread overview]
Message-ID: <20090402193827.GD4939@font.cl.cam.ac.uk> (raw)

Hi,

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.

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,

Stephen.

             reply	other threads:[~2009-04-02 19:38 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-04-02 19:38 Stephen Kell [this message]
2009-04-03  8:37 ` Andrew Haley
2009-04-03 10:35   ` Bryce McKinlay
     [not found]   ` <7230133d0904030328o55069f0do9147f879bcbd5e4f@mail.gmail.com>
2009-04-03 10:44     ` Andrew Haley
2009-04-03 18:54     ` Stephen Kell
2009-04-03 19:06       ` David Daney
2009-04-04  9:12       ` Andrew Haley
2009-04-03 13:57   ` Stephen Kell
2009-04-03 14:13     ` Andrew Haley
2009-04-03 18:42       ` Stephen Kell
  -- strict thread matches above, loose matches on Subject: below --
2000-04-01  0:00 Oskar Liljeblad
2000-04-01  0:00 ` Tom Tromey

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20090402193827.GD4939@font.cl.cam.ac.uk \
    --to=srk31@srcf.ucam.org \
    --cc=java@gcc.gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).