[Bug swing/23558] JComboBox problems (including VM crash)

[hendrich at informatik dot uni-hamburg dot de]

------- Additional Comments From hendrich at informatik dot uni-hamburg dot de  
2005-09-06 09:08 -------
Subject: Re:  JComboBox problems (including VM crash)

Hello Thomas,

> Nope; the crash I was seeing was a symptom of not specifying the -Y option to
> ssh.  So I still can't reproduce this on my laptop or my workstation with
> Graphics2D or just Graphics.

hmm. I updated my testcase to use Robot. See bugzilla.

Unfortunately, this doesn't work as I expected either (at least with ctwm):
Frame.setLocation() reports new values, but the Frame stays at the 
position that ctwm originally assigned to it... The values reported 
by Frame.getLocationOnScreen() and JComboBox.getLocationOnScreen() 
are also far from the truth :-(

Therefore, the testcase now includes two JComboBox'es and uses random
coordinates with manually-set sizes. It will generate events outside the
Java app (is there a way to get the position of the drop-down lists?),
so be careful.

Survives with the JDK, but fails after a few iterations with classpath
and jamvm 1.3.2. The Robot-version of the textcase regularly produces
these exceptions, but it seems to recover from them:

java.awt.IllegalComponentStateException: component javax.swing.JPopupMenu$HeavyW
eightPopup not showing
   at java.awt.Component.getLocationOnScreen (Component.java:1190)
   at gnu.java.awt.AWTUtilities.convertPointToScreen (AWTUtilities.java:538)
   at gnu.java.awt.AWTUtilities.convertPoint (AWTUtilities.java:596)
   at java.awt.LightweightDispatcher.acquireComponentForMouseEvent (Container.ja
va:1975)
   at java.awt.LightweightDispatcher.handleEvent (Container.java:2087)
   at java.awt.Container.dispatchEventImpl (Container.java:1583)
   at java.awt.Window.dispatchEventImpl (Window.java:628)
   at java.awt.Component.dispatchEvent (Component.java:2343)
   at java.awt.EventQueue.dispatchEvent (EventQueue.java:475)
   at java.awt.EventDispatchThread.run (EventDispatchThread.java:75)


The actual crash remains the same as before:

The program '.' received an X Window System error.
This probably reflects a bug in the program.
The error was 'BadWindow (invalid Window parameter)'.
  (Details: serial 17997 error_code 3 request_code 20 minor_code 0)


> Can you define SYNCHRONIZE_GDK to 1 in gtkpeer.h and try to get a backtrace? 
> It's a new debugging option I added to make debugging these X errors easier.

I'll try that when 0.18 is out. Rebuilding classpath should be easy enough,
but then I still won't have a reliable gdb...

- Norman



-- 


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