classpath
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: classpath pre-0.10, Jikes RVM, and AWT


From: Mark Wielaard
Subject: Re: classpath pre-0.10, Jikes RVM, and AWT
Date: Fri, 09 Jul 2004 16:49:27 +0200

Hi,

On Wed, 2004-07-07 at 23:56, Steven Augart wrote:
> Mark Wielaard discovered the problem, and I thank him for this.  Two
> major possiblities come to mind:
> 
>   1) There some problem that has been recently introduced, with
>      Classpath's C code (AWT), that is corrupting memory.  Jikes RVM
>      detects the problem; it should affect other VMs subtly too.
> 
>   2) There's a previously undetected memory corrupting bug in Jikes RVM.
> 
> I am still attempting to further locate the source of the corruption
> (have been doing so for about an hour and a half so far).  I do not
> know how long this will take to figure out.

I tried to pinpoint what was happening but unfortunately failed.
I did find some subtle initialization issues with the JNI environment
caching that I hopefully fixed in GNU Classpath CVS now. This did make a
crash on kissme disappear, but on jamvm I still (sometimes, but not
always!) get a crash on this simple program:

import java.awt.*;
public class B
{
  public static void main(String[] args)
  {
    Frame f = new Frame();
    f.setVisible(true);
    System.exit(0);
  }
}

And my patches also didn't solve the issue on rvm unfortunately.

Note that this simple program might actually show a design flaw in our
GTK+ peer setup. New Frame() will create the GtkMainThread() that stores
a global JNI environment reference (gdk_env)  which is then used in the
gtk callback triggered by the setVisible() method on another thread. It
seems the JNI spec does not guarantee that this works (it seems we will
need GetJavaVM, store that result and extract the JNI environment from
that on gtk call backs that don't happen on the main thread).

Unfortunately I couldn't get the enable-native-sync code working
properly with another runtime/JNI implementation out of the box. Kissme
unfortunately doesn't support GetJavaVM. And on jamvm, with
-Dgnu.classpath.awt.gtk.portable.native.sync=true I get:

jamvm: ../../../../classpath/native/jni/gtk-peer/gthread-jni.c:1397:
mutexObj_unlock: Assertion `potentialLockers >= 1' failed.

I decided to not hold up the release any longer though and will announce
0.10 soon. It is a nice improvement already, even when combined with rvm
compared to 0.09. After the release I will try to sync all gtk-peer and
jni-thread stuff with libcj and test it against gcj/gij. That might be
easier to debug if it turns out to be a bug in the JNI/GTK+ peer
implementation (gdb can just step through JNI or C/C++/GCJ native code
which helps enormously with debugging!).

Cheers,

Mark

Attachment: signature.asc
Description: This is a digitally signed message part


reply via email to

[Prev in Thread] Current Thread [Next in Thread]