[Bug AWT/21600] New: race condition with java applet

[Bug AWT/21600] New: race condition with java applet

[tromey at gcc dot gnu dot org]

I'm using the applet here:
http://www.chessgames.com/perl/chessgame?gid=1069669
with gcjappletviewer.
(As of this writing I needed a patch to make this work at all,
see the classpath-patches list.)

Sometimes running this applet works fine.
Other times, the window appears but it is very small.  When I resize it,
I see that the buttons are there, but the rest of the contents (the chess
board) are not.
It seems to start more reliably when I run gcjappletviewer in the debugger.

-- 
           Summary: race condition with java applet
           Product: gcc
           Version: 4.1.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P2
         Component: AWT
        AssignedTo: fitzsim at redhat dot com
        ReportedBy: tromey at gcc dot gnu dot org
                CC: gcc-bugs at gcc dot gnu dot org,java-prs at gcc dot gnu
                    dot org


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21600

[Bug AWT/21600] race condition with java applet

[fitzsim at redhat dot com]

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
     Ever Confirmed|                            |1
   Last reconfirmed|0000-00-00 00:00:00         |2005-05-25 01:59:31
               date|                            |


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21600

[Bug awt/21600] race condition with java applet

[fitzsim at redhat dot com]

------- Additional Comments From fitzsim at redhat dot com  2005-08-18 02:03 -------
This was a problem with locking in the GTK peers and interactions between the
main and event threads.

We connect a callback to the window realize signal.  In that callback we release
the GDK lock.  The 1x1 window appears when the main thread calls
GtkWindowPeer.nativeSetVisible.  That method obtains the GDK lock, then calls
gtk_widget_show.  That eventually calls the realize callback, which then
releases the GDK lock.  Now, with the window initialization sequence left
unlocked, the event dispatch thread can and does take control and receives a 1x1
configure event, before the window initialization is complete.  I'm not sure why
X/Metacity sends the bogus 1x1 configure event, but it only sends this within
this unlocked period.  If the lock is held during the callback we receive a
configure event with proper dimensions after window initialization is complete.

I fixed this by reworking the peers so that we never release the GDK lock within
callbacks.  It turns out this is never safe to do anyway, so it probably
eliminates other similar race conditions.

Closing.


-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |FIXED


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21600

[Bug awt/21600] race condition with java applet

[pinskia at gcc dot gnu dot org]

-- 

pinskia at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|---                         |0.18


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21600