From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 15298 invoked by alias); 21 Sep 2004 18:20:01 -0000 Mailing-List: contact java-prs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: java-prs-owner@gcc.gnu.org Received: (qmail 15172 invoked by uid 48); 21 Sep 2004 18:20:01 -0000 Date: Tue, 21 Sep 2004 18:20:00 -0000 Message-ID: <20040921182001.15171.qmail@sourceware.org> From: "tromey at gcc dot gnu dot org" To: java-prs@gcc.gnu.org In-Reply-To: <20040418092953.15001.thhal@mailblocks.com> References: <20040418092953.15001.thhal@mailblocks.com> Reply-To: gcc-bugzilla@gcc.gnu.org Subject: [Bug libgcj/15001] Using JNI with interpreter and interface methods yields SIGSEGV X-Bugzilla-Reason: CC X-SW-Source: 2004-q3/txt/msg00552.txt.bz2 List-Id: ------- Additional Comments From tromey at gcc dot gnu dot org 2004-09-21 18:19 ------- I looked at this a little, and wrote a test case that can be checked in whenever we're ready. This code is sort of a mess. A jmethodID doesn't have a pointer back to its declaring class, so we don't have an easy way to tell whether or not it came from an interface. We could search the "receiver" object's class hierarchy for the concrete method and use that, but this is inefficient. One question I have is why method->index is not -1 for a method declared in an interface. Perhaps declaring that this must be -1 for such methods is the simplest fix. Currently this is supposed to contain the dispatch index, but I don't see that we ever use that. Another approach would be to add a new flag to method->accflags indicating that it is an interface method. This is a hack, but would work. It would require going over bits of the runtime to ensure that we mask this bit out as appropriate, e.g. when adding Miranda methods to the concrete class hierarchy. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15001