[ImageJ-bugs] [Bug 835] Fiji hangs when installing macro tool

bugzilla at fiji.sc bugzilla at fiji.sc
Tue Aug 26 15:03:10 CDT 2014


http://fiji.sc/bugzilla/show_bug.cgi?id=835

Curtis Rueden <ctrueden at wisc.edu> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |ASSIGNED
                 CC|                            |imagej-bugs at imagej.net
           Assignee|imagej-bugs at imagej.net      |ctrueden at wisc.edu

--- Comment #15 from Curtis Rueden <ctrueden at wisc.edu> ---
> I didn't describe any hack for this

I was referring to the existence of the "isFiji" variable, which is a hack
inside ImageJ 1.x core. My preference would be for ImageJ 1.x not to care
whatsoever whether it is running from a Fiji installation or a vanilla one.
Having ImageJ 1.x detect a Fiji installation creates circular reasoning between
ImageJ1 and Fiji, with each part of the program trying to "work around" the
behavior of the other.

> One possibility is there is some unseen character in the file name.

This seems highly unlikely. However, you can easily verify that hypothesis for
yourself by trying something like "ls Postage_Action_Tool.ijm" (typing it all
out without tab completion) from the command line. If it works, then you got
the file name right.

> I think it is time for a minor overhaul on Menus.java

Unfortunately, it is probably far too late to make structural changes to
Menus.java without far-reaching consequences on backward compatibility.

> It used to be that Fiji was started by fiji-linux, but now ImageJ-linux32 is used.

That is not why the "isFiji" hack no longer works, though. The "title" in this
case refers to the title of the main window Frame.

> Fiji will hang and not accept any input from the menu or from the keyboard.
> I wanted to make a thread dump by using ctrl+\ but the keyboard had no response.

I ran Fiji from the command line on my OS X system and was able to generate a
stack trace after the program hang using Ctrl+\ on the console. Here are the
relevant parts:

"SciJava-4a0ece36-Thread-2" prio=5 tid=115aa6000 nid=0x12232a000 in
Object.wait() [122329000]
   java.lang.Thread.State: WAITING (on object monitor)
    at java.lang.Object.wait(Native Method)
    - waiting on <6c62f46c0> (a java.awt.EventQueue$1AWTInvocationLock)
    at java.lang.Object.wait(Object.java:485)
    at java.awt.EventQueue.invokeAndWait(EventQueue.java:1121)
    - locked <6c62f46c0> (a java.awt.EventQueue$1AWTInvocationLock)
    at java.awt.EventQueue.invokeAndWait(EventQueue.java:1103)
    at
org.scijava.thread.DefaultThreadService.invoke(DefaultThreadService.java:98)
    at org.scijava.event.DefaultEventBus.publishNow(DefaultEventBus.java:191)
    at org.scijava.event.DefaultEventBus.publishNow(DefaultEventBus.java:82)
    at
org.scijava.event.DefaultEventService.publish(DefaultEventService.java:94)
    at org.scijava.module.ModuleRunner.run(ModuleRunner.java:153)
    at org.scijava.module.ModuleRunner.call(ModuleRunner.java:126)
    at org.scijava.module.ModuleRunner.call(ModuleRunner.java:65)
    at
org.scijava.thread.DefaultThreadService$2.call(DefaultThreadService.java:164)
    at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
    at java.util.concurrent.FutureTask.run(FutureTask.java:138)
    at
java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:895)
    at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:918)
    at java.lang.Thread.run(Thread.java:695)

"Run$_AWT-EventQueue-0" prio=6 tid=106c61800 nid=0x11d66a000 waiting on
condition [11d667000]
   java.lang.Thread.State: WAITING (parking)
    at sun.misc.Unsafe.park(Native Method)
    - parking to wait for  <6c634e290> (a java.util.concurrent.FutureTask$Sync)
    at java.util.concurrent.locks.LockSupport.park(LockSupport.java:156)
    at
java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:811)
    at
java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireSharedInterruptibly(AbstractQueuedSynchronizer.java:969)
    at
java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireSharedInterruptibly(AbstractQueuedSynchronizer.java:1281)
    at java.util.concurrent.FutureTask$Sync.innerGet(FutureTask.java:218)
    at java.util.concurrent.FutureTask.get(FutureTask.java:83)
    at
net.imagej.legacy.DefaultLegacyService.runLegacyCompatibleCommand(DefaultLegacyService.java:267)
    at
net.imagej.legacy.DefaultLegacyHooks.interceptRunPlugIn(DefaultLegacyHooks.java:160)
    at ij.IJ.runPlugIn(IJ.java)
    at ij.Executer.runCommand(Executer.java:131)
    at ij.Executer.run(Executer.java:64)
    at ij.IJ.run(IJ.java:272)
    at ij.IJ.run(IJ.java:250)
    at ij.gui.Toolbar.itemStateChanged(Toolbar.java:1270)

In English:
- ImageJ1 invokes the macro using IJ.runPlugIn.
- ImageJ2's legacy service intercepts the execution, and executes the macro
using the SciJava scripting framework.
- This launches a new thread ("SciJava-4a0ece36-Thread-2" in this case), and
blocks until execution is complete.
- On the new thread, the SciJava module framework tries to broadcast a
ModuleStartedEvent, blocking till event handling is complete.
- Deadlock occurs as each thread is blocking the other.

> In Fiji, when I select Plugins>Tools>Postage Action Tool, the tool is not
> installed. Instead, "Tile" is displayed in the Log window. This is a bug.

Yes, that is a separate bug, caused by the fact that the macro is executed
using the SciJava scripting framework, which works differently.

I am investigating how to fix the deadlock right now, and will keep you posted.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://imagej.net/pipermail/imagej-bugs/attachments/20140826/bcbd21ce/attachment.html>


More information about the Imagej-bugs mailing list