Posted by
Fred Damen on
Sep 07, 2020; 7:51pm
URL: http://imagej.273.s1.nabble.com/GenericDialog-and-imagej-lockups-tp5023908p5023917.html
Greetings Michael,
Questions (asked out of ignorance / not as a challenge) inline...
Thanks,
Fred
On Mon, September 7, 2020 7:25 am, Michael Schmid wrote:
> Hi Fred,
>
> not a clear solution, but one of the threads causing the deadlock is
> related to closing an image. Please check your WindowListener!
1) How, using the stack traces, to correlate the "Close" thread with the
"DICOM_open" thread? I assume the subject resource of each of their locks
is identified by the number in <>, and they are different.
2) Logically why would a GenericDialog care, or even know, about a
WindowListener of a image window?, i.e., the WindowListeners are object
specific and as such they are only called for the window they were
register against, i.e, not like ImageListeners. At the point of lockup
there are no other windows, besides the main window, opened.
2.1) Multiple WindowListeners should be allowed and called independent of
thread safety; where the lockup only comes to play when more than one
thread tries to lock the same resource.
>
> (1) Is it guaranteed that you call removeWindowListener before
> Diffusion_Multimodal exits?
3) "Diffusion_Multimodal exits" is a little nebulous. The run method that
was called when Diffusion_Multimodal was run as a plugin has returned. At
this point the WindowListeners for the source or results windows have not
been removed. When one of the results windows are closed, the
WindowListeners (all listeners) are removed for all the results and source
windows.
3.1) I have included the source code that preforms this, in case someone
can spot something I missed, n.b., dimp is the same as imp.
3.2) I have added this after removing the window listener:
for(WindowListener wl : dimp.getWindow().getWindowListeners())
IJ.log("WindowListeners: "+wl);
and it produced this:
WindowListeners: Trace - Untitled
WindowListeners: sun.awt.im.InputMethodContext@5e0e286e
I assume the first is imagej's (as that is the window title) and the other
is Java's WindowListener.
> (Note that it does not hurt to call a 'remove' from a listener too
> often. It does hurt to call 'add' for a listener more than once, because
> then the listener will be entered more than once, get callbacks more
> than once, and must be removed more than once).
4) I assume that once the Window is closed, all the WindowListeners
registered for this Window are removed.
> (2) If Diffusion_Multimodal has ended and its windowClosed or
> WindowClosing method would get called, could it do something that (i)
> makes it hang or (ii) leads to something being called on the EventQueue
> or something that modifies the screen?
5) Not that I can tell. The only thing the WindowListener does is close
all the results windows. The Mouse and Key listeners cause a plot of the
currently selected voxel. In the testing I did for the posting of this
issue there is no key or mouse action going on.
6) Why would this effect the GenericDialog in the DICOM_open plugin?
> (3) If you use any swing calls (jvax.swing, not AWT), note that swing is
> not thread-safe. Typically, you should call swing functions only via
> SwingUtilities.invokeLater.
7) The only GUI stuff I used in these two plugin(s) is GenericDialog. I
included the GenericDialog usage code from DICOM_open.
>
>
> Michael
> ________________________________________________________________
> On 04.09.20 21:33, Fred Damen wrote:
>> Greetings,
>>
>> I am able to consitently get imagej to lock up, and I am a loss at what
>> I
>> am directly or indirectly doing to cause this. The scenario is:
>> my plugin DICOM_open creates a GenericDialog with an addDialogListener,
>> which displays and after showDialog returns opens a set of DICOM files
>> as
>> a hyperstack. After this I run another plugin, Diffusion_Multimodal,
>> which creates a GenericDialog and after the showDialog processes this
>> hyperstack creating a set of images in windows; these windows have
>> listeners - method that add and removes listener is below. Closing the
>> hyperstack and running DICOM_open again causes imagej to lockup within
>> showDialog, see first entry in thread stack traces.
>>
>> I can run DICOM_open only, over and over again, without any lockup. I
>> can
>> run Diffusion_Multimodal, after the first DICOM_open, over and over
>> again
>> without any lockup. Although, running DICOM_open after
>> Diffusion_Multimodal lockups everytime. I have run this code lots and
>> lots in the past and do not remember this scenario ever happening.
>>
>> I discovered this on release 1.52u14 and confirmed it still happens on
>> 1.53e14. Any insites and / or suggestion on how to debug this would be
>> greatly appriciated.
>>
>> Thanks in advance,
>>
>> Fred
>
> --
> ImageJ mailing list:
http://imagej.nih.gov/ij/list.html>
--
ImageJ mailing list:
http://imagej.nih.gov/ij/list.html