JDK-4455101 : Menu repaint problems on solaris.
  • Type: Bug
  • Component: client-libs
  • Sub-Component: javax.swing
  • Affected Version: 1.4.0
  • Priority: P1
  • Status: Closed
  • Resolution: Duplicate
  • OS: solaris_8
  • CPU: sparc
  • Submitted: 2001-05-07
  • Updated: 2001-05-09
  • Resolved: 2001-05-09
Related Reports
Duplicate :  
JDK-4419252 - Expose events being incorrectly generated
Description
On solaris when browsing through menu structure it is often repainted. It
happens when the menu has some submenus and no matter if it is JPopupMenu or
JMenu. Sometimes there are some menus missing in the expanded menu menu
structure. This was observed on Merlin b63 on Solaris 5.8. On windows systems
this seems to work well. We need this to have fixed for FFJ.
Attaching simple demonstrating example.

Example added.

jan.zajicek@Czech 2001-05-07

correcting the build of Merlin to 63
jan.zajicek@Czech 2001-05-07
Comments
EVALUATION If you do the following: click on the first Menu click on the sub menu 'Menu' click on its sub menu 'Menu' then the CPU becomes pegged and the app is unable to do anything. Here is the state of the threads at this point: Full thread dump: "TimerQueue" daemon prio=5 tid=0x158da8 nid=0x11 waiting on monitor [70381000..70381a28] at java.lang.Object.wait(Native Method) - waiting on <74d63d88> (a javax.swing.TimerQueue) at javax.swing.TimerQueue.run(TimerQueue.java:234) - locked <74d63d88> (a javax.swing.TimerQueue) at java.lang.Thread.run(Thread.java:579) "Thread-3" prio=5 tid=0x28ae0 nid=0x1 waiting on monitor [0..ffbee3d0] "AWT-EventQueue-0" prio=6 tid=0x1e6868 nid=0x10 waiting for monitor entry [74501000..74501a28] at java.awt.AWTEvent.nativeSetSource(Native Method) at java.awt.AWTEvent.setSource(AWTEvent.java:271) - locked <74d8cb10> (a java.awt.event.FocusEvent) at java.awt.DefaultKeyboardFocusManager.dispatchEvent(DefaultKeyboardFocusManager.java:443) at java.awt.Component.dispatchEventImpl(Component.java:3367) at java.awt.Container.dispatchEventImpl(Container.java:1399) at java.awt.Window.dispatchEventImpl(Window.java:1459) at java.awt.Component.dispatchEvent(Component.java:3343) at java.awt.EventQueue.dispatchEvent(EventQueue.java:439) at java.awt.SequencedEvent.dispatch(SequencedEvent.java:96) at java.awt.EventQueue.dispatchEvent(EventQueue.java:437) at java.awt.EventDispatchThread.pumpOneEvent(EventDispatchThread.java:150) at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:136) at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:131) at java.awt.EventDispatchThread.run(EventDispatchThread.java:99) "Thread-1" daemon prio=5 tid=0xdca98 nid=0xf waiting on monitor [74601000..74601a28] at java.lang.Object.wait(Native Method) - waiting on <74d39b90> (a java.util.TaskQueue) at java.util.TimerThread.mainLoop(Timer.java:432) - locked <74d39b90> (a java.util.TaskQueue) at java.util.TimerThread.run(Timer.java:385) "AWT-Shutdown" prio=6 tid=0xd78c8 nid=0xe waiting on monitor [74801000..74801a28] at java.lang.Object.wait(Native Method) - waiting on <74e10118> (a java.lang.Object) at java.lang.Object.wait(Object.java:425) at sun.awt.AWTAutoShutdown.run(AWTAutoShutdown.java:262) - locked <74e10118> (a java.lang.Object) at java.lang.Thread.run(Thread.java:579) "AWT-Motif" daemon prio=6 tid=0x111b60 nid=0xd runnable [74701000..74701a28] at sun.awt.motif.MToolkit.run(Native Method) at java.lang.Thread.run(Thread.java:579) "Signal Dispatcher" daemon prio=10 tid=0x98c68 nid=0xa waiting on monitor [0..0] "Finalizer" daemon prio=8 tid=0x94f18 nid=0x7 waiting on monitor [7d381000..7d381a28] at java.lang.Object.wait(Native Method) - waiting on <74e10218> (a java.lang.ref.ReferenceQueue$Lock) at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:111) - locked <74e10218> (a java.lang.ref.ReferenceQueue$Lock) at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:126) at java.lang.ref.Finalizer$FinalizerThread.run(Finalizer.java:162) "Reference Handler" daemon prio=10 tid=0x93690 nid=0x6 waiting on monitor [7e981000..7e981a28] at java.lang.Object.wait(Native Method) - waiting on <74e10278> (a java.lang.ref.Reference$Lock) at java.lang.Object.wait(Object.java:425) at java.lang.ref.Reference$ReferenceHandler.run(Reference.java:110) - locked <74e10278> (a java.lang.ref.Reference$Lock) "VM Thread" prio=5 tid=0x92358 nid=0x4 runnable "VM Periodic Task Thread" prio=10 tid=0x97490 nid=0x8 waiting on monitor "Suspend Checker Thread" prio=10 tid=0x98380 nid=0x9 runnable I've emailed submitter to make sure this is what was encountered. scott.violet@eng 2001-05-07 I have to say that this didn't happen to me. I created the simple example only to ilustrate the repaint problem on Solaris, because FFJ is too large to demonstrate in it. I pointed to the fact that when selecting the items in JMenuBar the whole MenuBar blinks. The same happens when expand first Menu, then 'Menu' and 'Menu' and now do not leave with mouse cursor the middle submenu and move down to the last 'Item', at this moment is the whole expanded menu structure repainted again (you need to have the app window resized to see this). I have to note that this was observed only on Solaris. jan.zajicek@Czech 2001-05-07 The repainting is already filed as 4419252. As such, I'm closing this bug as a duplicate of that bug, and opening a new bug for the CPU pegging I was seeing above (4456364). scott.violet@eng 2001-05-09
09-05-2001