While having a look at the one memory leak regard currently reports, I came across an unrelated threading problem. It can be triggered (at least on my computer) by setting the animation rate limiting mode to Unlimited, and then opening a simple document with animation, e.g.:
<svg xmlns="http://www.w3.org/2000/svg"; width="400" height="300"> <circle id="something" cx="50" cy="50" r="50"> <animate attributeName="r" begin="0s" dur="5s" values="50; 0; 50" repeatDur="indefinite"/> </circle> </svg> While the animation is running, press Ctrl+W to close the window. The interface then hangs. Pressing Ctrl+\ shows me the two threads that are effectively deadlocked: "RunnableQueue-0" daemon prio=1 tid=0x081ae770 nid=0x62ea in Object.wait() [0xb09c6000..0xb09c7140] at java.lang.Object.wait(Native Method) at java.lang.Object.wait(Object.java:474) at java.awt.EventQueue.invokeAndWait(EventQueue.java:846) - locked <0x6ca13778> (a java.awt.EventQueue$1AWTInvocationLock) at org.apache.batik.swing.svg.AbstractJSVGComponent$SVGListener.updateCompleted(AbstractJSVGComponent.java:1969) at org.apache.batik.bridge.UpdateManager$9.dispatch(UpdateManager.java:826) at org.apache.batik.util.EventDispatcher.dispatchEvent(EventDispatcher.java:103) at org.apache.batik.util.EventDispatcher.fireEvent(EventDispatcher.java:87) at org.apache.batik.bridge.UpdateManager.fireEvent(UpdateManager.java:755) at org.apache.batik.bridge.UpdateManager.updateRendering(UpdateManager.java:514) at org.apache.batik.bridge.UpdateManager.repaint(UpdateManager.java:571) at org.apache.batik.bridge.UpdateManager$UpdateManagerRunHander.runnableInvoked(UpdateManager.java:869) at org.apache.batik.util.RunnableQueue.runnableInvoked(RunnableQueue.java:543) - locked <0x6f57bc30> (a org.apache.batik.util.RunnableQueue) at org.apache.batik.util.RunnableQueue.run(RunnableQueue.java:251) at java.lang.Thread.run(Thread.java:595) "AWT-EventQueue-0" prio=1 tid=0x08548718 nid=0x62e1 waiting for monitor entry [0xb10af000..0xb10afec0] at org.apache.batik.bridge.UpdateManager.interrupt(UpdateManager.java:384) - waiting to lock <0x6f57bc30> (a org.apache.batik.util.RunnableQueue) - locked <0x6f57e9e0> (a org.apache.batik.bridge.UpdateManager) at org.apache.batik.swing.svg.AbstractJSVGComponent.stopProcessing(AbstractJSVGComponent.java:574) at org.apache.batik.apps.svgbrowser.Main.closeJSVGViewerFrame(Main.java:700) at org.apache.batik.apps.svgbrowser.JSVGViewerFrame$CloseAction.actionPerformed(JSVGViewerFrame.java:1362) at javax.swing.AbstractButton.fireActionPerformed(AbstractButton.java:1849) ... at javax.swing.JComponent.processKeyEvent(JComponent.java:2726) ... at java.awt.EventDispatchThread.run(EventDispatchThread.java:110) So each time a rendering update is completed, the UpdateManagerRunHander is sent to the RunnableQueue, which locks on the RunnableQueue. The JSVGComponent’s updateCompleted listener calls EventQueue.invokeAndWait, locking on the AWT thread. Meanwhile, the AWT thread is already midway through processing the Ctrl+W to close the window. But UpdateManager.interrupt synchronizes on the RunnableQueue, so the AWT thread lock is never released. Threading issues aren’t my forte. How should we avoid this? -- Cameron McCormack, http://mcc.id.au/ xmpp:[EMAIL PROTECTED] ▪ ICQ 26955922 ▪ MSN [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
