Details
-
Type:
Bug
-
Status: Closed (View Workflow)
-
Priority:
Critical
-
Resolution: Done
-
Affects Version/s: None
-
Fix Version/s: None
-
Labels:None
-
Story Points:1
Description
When attempting to open a local file in IGB using the File -> Open File menu, IGB enters nonresponsive state - the application hangs, with a spinning color wheel. The same occurs if, when managing repositories from within the app manager, a local folder is added or edited. The issue is present on IGB 9.1.0 as well as in IGB 9.0.0 and 9.0.2, however in the two 9.0.x versions tested, attempting File -> Open File results in the error shown in the attachment 9.0.x_fileOpenError.png; attempting to add through the data source manager results in behavior similar to that described for version 9.1.0.
CPU and memory usage are low and do not change, so it isn't likely that this is due to a lack of hardware resources. It may be the result of an OS-level incompatibility with IGB, although Nowlan Freese informed me that no such issues were previously present, when running IGB on macOS high sierra, but it may be due to a version difference. I experienced the bug on version 10.13.6 (17G65) of macOS high sierra, running on a MacBook Pro (13-inch, Early 2011).
Loading local files using File -> Open URL works without issue. e.g. file:///Users/philip/Documents/development/A_thaliana_Jun_2009.2bit
- Check if this issue can be replicated on another system running the latest version of macOS high sierra and report here.
- Identify the cause of the issue.
Attachments
Issue Links
Activity
This may be helpful - a JavaFX bug report dating from 2015 that affected MacOS only:
"Mac: javafx.stage.FileChooser().setInitialDirectory(file) not working"
https://bugs.openjdk.java.net/browse/JDK-8126470
Rebooting the system resolved the issue. It may be that some cached temp files were flushed or that the resulting clean state removed a deadlock between tasks - which may have been only those internal to IGB but could also involve other applications/OS processes running on the system.
For future reference, the concrete issue was that the runLater Runnable code in saveFilesFromFxChooser() of FileChooserUtil.java was never executed, resulting in an infinite wait/lock on a javaFx thread. I have also observed the following warning, which is the result of OS-level design:
objc[17137]: Class FIFinderSyncExtensionHost is implemented in both /System/Library/PrivateFrameworks/FinderKit.framework/Versions/A/FinderKit (0x7fff96f6bc90) and /System/Library/PrivateFrameworks/FileProvider.framework/OverrideBundles/FinderSyncCollaborationFileProviderOverride.bundle/Contents/MacOS/FinderSyncCollaborationFileProviderOverride (0x15ab06cd8). One of the two will be used. Which one is undefined.
The issue seems to come back randomly. Restarting the WindowServer process resolves the issue, however, in doing so, the user is logged out and all applications are restarted. Manually quitting all open applications didn't resolve the issue, so it seems it would be either with the WindowServer process or in some other process that is restarted when WindowServer is.
We have never been able to reproduce this problem. Moving to Closed.
I am unsure if the values for some of the fields in the currDir variable are correct/expected. currDir is passed into the FileChooserUtil class, so verifying that its parameters are okay could provide some insight into why the thread runnable in line 174 of FileChooserUtil.java is never executed. If someone could pause at a breakpoint at line 174 in LoadFileAction.java, after clicking File -> Open in IGB on a machine on which this issue doesn't occur, reporting the values in currDir could be useful for comparison.
Edit: The values of CurrDir don't seem to be the cause of this issue, as they are the same between runs with the issue and those without it.