On Fri, Feb 13, 2009 at 11:31 PM, Roman Kennke <[email protected]> wrote: > Hi Oleg, > >> as far as I can see hideAndDisposeHandler() called either from hide() >> (if it is not called by dispose()) or >> from doDispose(), but after super.doDispose() is executed. > > You are right. My original analysis was not correct. The problem is a little > diferent, the application I have here calls hide() and dispose() one after > the other, which then causes this situation, hideAndDisposeHandler() called > first, followed quickly by Window.doDispose(). The attached test program > demonstrates the problem. Not executing the DisposeAction immediately, but > instead sending it over the EQ solves the problem by bringing the actions > into correct order. This would be a good case for testing the brand new > bugzilla, no? ;-)
Yes, I agree with you. Now you have good bugreport (and good bug to report ;) to test new system :) Oleg. > > /Roman > > So, from >> >> your description it is not clear >> how Window.doDispose() for the dialog can be executed after >> hideAndDisposeHandler() :( >> >> Perhaps if you start your description from the very top of the call >> stack it would provide enough information >> to understand that. >> >> With best regards, Oleg. >> >> On Fri, Feb 13, 2009 at 7:54 PM, Roman Kennke <[email protected]> >> wrote: >>> >>> Hi there, >>> >>> I have a strange problem with modal dialogs here. I have a modal dialog, >>> which is never released, even though it is disposed. What happens is >>> this: >>> in Dialog.hideAndDisposeHandler() the waking event is correctly posted to >>> the EQ. Then doDispose() continues in Window.doDispose(), where a >>> DisposeAction is created. Then it finds that it is on the EDT and >>> immediately executes this action. This in turn calls removeNotify(), >>> which >>> then leads to all events that are related to the dialog to be removed >>> from >>> the EQ, including the waking event. Thus, the Dialog is never released >>> and >>> the thread that opened the dialog is stuck forever, since nobody will >>> notify() it. It can easily be solved in Window.doDispose(), just remove >>> that >>> if (EventQueue.isDispatchThread()) check. >>> >>> Unfortunately I have no easy testcase to reproduce. I found this in >>> JamaicaVM w/ DirectFB/Caciocavallo. It is not unlikely that this only >>> happens because we have different thread scheduling than Hotspot, or I >>> might >>> even think wrong and something is missing to me. >>> >>> Any ideas? Is this a bug? Am I thinking in the wrong direction? >>> >>> /Roman >>> >>> -- >>> Dipl.-Inform. (FH) Roman Kennke, Software Engineer, http://kennke.org >>> aicas Allerton Interworks Computer Automated Systems GmbH >>> Haid-und-Neu-Straße 18 * D-76131 Karlsruhe * Germany >>> http://www.aicas.com * Tel: +49-721-663 968-48 >>> USt-Id: DE216375633, Handelsregister HRB 109481, AG Karlsruhe >>> Geschäftsführer: Dr. James J. Hunt >>> > > > -- > Dipl.-Inform. (FH) Roman Kennke, Software Engineer, http://kennke.org > aicas Allerton Interworks Computer Automated Systems GmbH > Haid-und-Neu-Straße 18 * D-76131 Karlsruhe * Germany > http://www.aicas.com * Tel: +49-721-663 968-48 > USt-Id: DE216375633, Handelsregister HRB 109481, AG Karlsruhe > Geschäftsführer: Dr. James J. Hunt >
