This is the mail archive of the
java@gcc.gnu.org
mailing list for the Java project.
Re: Problems with libjava's AWT
- From: Thomas Fitzsimmons <fitzsim at redhat dot com>
- To: Bernd Schmidt <bernds at btinternet dot com>
- Cc: java at gcc dot gnu dot org, libgcj patches <java-patches at gcc dot gnu dot org>
- Date: Mon, 07 Jun 2004 14:56:28 -0400
- Subject: Re: Problems with libjava's AWT
- References: <Pine.LNX.4.58.0406061352490.6420@tesuji.local>
On Sun, 2004-06-06 at 09:09, Bernd Schmidt wrote:
> I'm trying to compile a Java program (jago, http://www.rene-grothmann.de/jago/)
> with a recent CVS version of gcj. It compiles fine once I remove all
> attempts to generate sound from the code.
If you're interested in tracking AWT and Swing development, you may want
to try the java-gui-branch. That is where most new GUI development is
taking place. We do monthly merges with mainline though, if you're
willing to wait that long.
> However, it seems to run into
> a number of problems with the AWT implementation in libjava.
>
> Once started, the program just hangs. I traced this to a call to wait in
> MediaTracker::waitForAll. What seems to happen is this:
> - The program calls MediaTracker::addImage, which
> - calls GtkToolkit::checkImage, which
> - calls observer.ImageUpdate with "flags" set to 0.
> - In MediaTracker::MediaEntry::imageUpdate, a value of 0 for "flags"
> is translated (by default) into a "status" of LOADING. This
> appears to be premature.
> - The program then calls MediaTracker::waitForAll, which
> - calls MediaTracker::checkAll, which
> - sees that we set a status of LOADING for the image, so it doesn't
> call prepareImage (apparently believing it has been called already)
> - back in MediaTracker::waitForAll, we end up in an infinte wait().
>
> At the very least, the patch I'm appending below seems necessary to
> leave "status" at 0 if imageUpdate is given a zero "flags".
Yes, I think you're right. I've committed your patch on the
java-gui-branch.
> The program
> then gets a bit further, but it still hangs up in the same wait(). This
> seems to be a genuine deadlock: we have a thread running wait() inside
> a synchronized{} block, while another thread is running imageUpdate, trying
> to notify the other thread that it can stop waiting, but unable to enter
> the critical section (because the thread wait()ing has it blocked).
>
> The locking in here seems broken, and I don't see a good way to fix it.
> I'm not much of a Java expert; could anyone tell me if there are
> message-passing APIs available which I could use?
>
> Has this code been tested - are there other programs that work with gcj
> and which use this part of libjava?
>
Yes, we have an internal bug report about this (that we will soon push
to GCC bugzilla along with our other internal bugs). I looked at this
deadlock briefly, but then got distracted by other things. This is a
pretty critical problem, so I'll look at it again soon (unless you beat
me to it ;-)
Tom
>
> Bernd
>
> * java/awt/MediaTracker.java (imageUpdate): Only set status to
> LOADING if flags has SOMEBITS set.
>
> Index: java/awt/MediaTracker.java
> ===================================================================
> RCS file: /cvs/gcc/gcc/libjava/java/awt/MediaTracker.java,v
> retrieving revision 1.5
> diff -d -p -u -r1.5 MediaTracker.java
> --- java/awt/MediaTracker.java 12 Nov 2003 00:37:34 -0000 1.5
> +++ java/awt/MediaTracker.java 6 Jun 2004 13:02:44 -0000
> @@ -81,13 +81,15 @@ public class MediaTracker implements jav
> status = ERRORED | COMPLETE;
> else if ((flags & ALLBITS) != 0)
> status = COMPLETE;
> - else
> + else if ((flags & SOMEBITS) != 0)
> status = LOADING;
> -
> + else
> + status = 0;
> +
> synchronized (MediaTracker.this)
> {
> MediaTracker.this.notifyAll();
> }
> // If status is not COMPLETE then we need more updates.
> return (status & COMPLETE) == 0;
> }