Support #894

TXM: 0.7.6beta, TXM freeze during splash screen on Mac OS X

Added by Matthieu Decorde almost 5 years ago. Updated about 3 years ago.

Status:Closed Start date:07/01/2014
Priority:Immediate Due date:
Assignee:- % Done:

100%

Category:Démarrage Spent time: -
Target version:TXM 0.7.7

Description

Only for Mac OS X, TXM freezes during its initialization and the splash screen never ends.

Hypothesis 1 :
It seems to be due to a SWT/AWT mix problem. We can't neither identify nor reproduce this bug at this moment. It may be linked to specific configuration (there are some known bugs in JVM 7 + Cocoa according to the JVM version).
It may be due to JFreeChart initialization during the Toolbox initialization that causes a deadlock with the UI thread. "ImageIO.getWriterFormatNames();" call (in ChartsEngine.populateSupportedOutputRasterFileFormats) may be the reason.

Solution 1
For Mac OS X, deactivate the call to ImageIO

Conclusion 1
I still had a few hang up after this fix but I don't know if it's the same problem.

Solution 2
Another solution may be to lazy initialize the ChartEngine just before we need it. And then avoid UI thread deadlock.

Solution 3
Since we can not reproduce this bug, wait until we can study an involved machine where the hang up occurs and get some information about the JVM threads stack to exactly determine which class are involved in the blocking process.

Temporary workaround

If TXM freezes at splash screen on Mac OS X, to kill TXM process, press CMD + ALT + ESC then select TXM in the opened dialog box then "Force Quit" and confirm.

Starting TXM with R charts engine does not hang up. So we can edit "$HOME/.txm/configuration/.settings/org.txm.rcpapplication.prefs" to force the R/SVG mode, then run TXM, the 2 involved parameters/lines should be replaced as following:
OR
Export TXM preferences, edit the exported ".properties" file and reimport the preferences with the ".properties" file

charts_engine_name=r_charts_engine
charts_engine_output_format=svg

Once it launched, use the parameters UI entry to switch back to JFC charts engine.

Validation test

Run TXM with Mac OS X.

MD: OK Mac OS X 10.6, JVM Apple 1.6.0_65

History

#1 Updated by Matthieu Decorde almost 5 years ago

  • Description updated (diff)

#2 Updated by Matthieu Decorde almost 5 years ago

  • Description updated (diff)

#3 Updated by Sebastien Jacquot almost 5 years ago

The problem is not reproducible at this moment. Tests have been successful, with no freeze under :
- Maverick 10.9 64 bits + Apple/Sun Java 1.6.0_65 from 0.7.5 setup + 2014.06.18 beta update
- Maverick 10.9 64 bits + Oracle Java 1.7.0_55 from 0.7.5 setup + 2014.06.18 beta update
- Maverick 10.9 64 bits + Apple/Sun Java 1.6.0_65 from latest SVN source + Eclipse Build
- Maverick 10.9 64 bits + Oracle Java 1.7.0_55 from latest SVN source + Eclipse Build

#4 Updated by Sebastien Jacquot almost 5 years ago

More tests have been successful, with no freeze under :
- Maverick 10.9.4 64 bits + Apple/Sun Java 1.6.0_65 from 0.7.5 setup + 2014.06.18 beta update
- Maverick 10.9.4 64 bits + Oracle Java 1.7.0_55 from 0.7.5 setup + 2014.06.18 beta update
- Maverick 10.9.4 64 bits + Apple/Sun Java 1.6.0_65 from latest SVN source + Eclipse Build
- Maverick 10.9.4 64 bits + Oracle Java 1.7.0_55 from latest SVN source + Eclipse Build

#5 Updated by Sebastien Jacquot almost 5 years ago

New tests have been made using :
- Maverick 10.9.4 64 bits + Oracle Java 1.7.0_55 from 0.7.5 setup + 2014.06.18 beta update
The problem is linked to the inexistent preferences 'charts_engine_output_format' in org.txm.rcpapplication.prefs after having made an update that use it.
The previous tests from setup were wrong because the update was restoring the org.txm.rcpapplication.prefs file from /tmp/org.txm.rcpapplication.prefs that already contains the new preference. (Is this tmp file really useful ? In which case is it used ?)
A temporary workaround is to open the org.txm.rcpapplication.prefs file and add this line:
charts_engine_output_format=JFreeChart/Java2D

#6 Updated by Sebastien Jacquot almost 5 years ago

  • Status changed from New to Resolved
  • % Done changed from 0 to 80

The bug comes from an ImageIO.getWriterFormatNames() call to populate raster supported file formats of JFCChartsEngine which seems to leads to a deadlock if called too early during the SWT initialization process, the reason of this behavior has not been clearly identified.
The bug has been fixed by calling ChartsEngine.populateSupportedOutputRasterFileFormats() during the creation of the JFC charts engine rather than in a static block.

#7 Updated by Sebastien Jacquot almost 5 years ago

The fix included in the DEV update 0.7.6.201407031220 has been successfully tested on Maverick 10.9.4 64 bits + Oracle Java 1.7.0_55.

#8 Updated by Matthieu Decorde almost 5 years ago

  • % Done changed from 80 to 90

Beta tested

#9 Updated by Matthieu Decorde almost 5 years ago

  • Category changed from UI to Démarrage

#10 Updated by Matthieu Decorde over 4 years ago

  • % Done changed from 90 to 100

#11 Updated by Matthieu Decorde over 4 years ago

  • Status changed from Resolved to Closed

#12 Updated by Matthieu Decorde over 4 years ago

  • Description updated (diff)

#13 Updated by Matthieu Decorde over 4 years ago

  • Status changed from Closed to In Progress

#14 Updated by Matthieu Decorde over 4 years ago

  • % Done changed from 100 to 80

#15 Updated by Matthieu Decorde over 4 years ago

  • % Done changed from 80 to 70

#16 Updated by Sebastien Jacquot over 4 years ago

  • Priority changed from Normal to Immediate
  • Target version changed from TXM 0.7.6 to TXM 0.7.7

#17 Updated by Sebastien Jacquot over 4 years ago

To fix this bug, the usage of ImageIO.getWriterFormatNames() has been removed.
The supported raster formats of JFCChartsEngine are now hardly coded as PNG, JPG, BMP, GIF and not anymore auto-detected at runtime. It may causes troubles on some operating systems if they don't manage one of these raster formats.

#18 Updated by Matthieu Decorde over 4 years ago

  • % Done changed from 70 to 80

no freeze after Run run test with Mac OS X 10.6 and 10.9

#19 Updated by Matthieu Decorde over 4 years ago

  • Status changed from In Progress to Feedback

#20 Updated by Sebastien Jacquot over 4 years ago

I still have some deadlocks sometimes at splashcreen on OS 10.9.4.
NOTE:
After some research, even an awt.Color instantiation seems to be able to lead to a deadlock on OS X when using AWT/SWT couple.
It starts the AWT event loop which may conflict/deadlock with SWT event loop.

In JFC charts engine, the HighChartsDefaultTheme/Theme classes initialization in Toolbox instantiate a bunch of AWT non-component classes but that could be involved in the deadlock behavior: awt.Font, awt.Color, etc.

The theme may be lazy loaded in createChartsXXXX() methods of JFCChartsEngine or loaded in the Main UI thread (invokeLater ?).
The first solution seems not very good. It involves addition of a lot of code and some useless tests at execution time. And it's totally useless in the portal environment.
The second solution seems better but the Toolbox should be initialized after the complete initialization of the RCP UI.
(By doing that we also may be able to reestablish the automatic detection of raster formats JVM capabilities ImageIO, see: ChartsEngine.populateSupportedOutputRasterFileFormats())

#21 Updated by Sebastien Jacquot over 4 years ago

After further tests with tiny test case:
Windows: the AWT event thread is NOT started when instantiating an awt.Color or an awt.Font object, at least with JVM 1.7
OS X: a thread called AWT-AppKit is ALWAYS started even if no import/instantiation/reference to some AWT classes are made in the code but the AWT-EventQueue thread is NOT started

Actually since the freeze occurs during splash screen and Eclipse bundles loading, I wonder how it could be caused by some code in the Tooblox initialization.

#22 Updated by Sebastien Jacquot over 4 years ago

IMPORTANT NOTE: it seems any bundle/plugin which manipulates AWT/Swing on its initialization (typically when loaded at startup before UI) can cause a deadlock on Cocoa/OS X when using a splash screen. The splash screen is a SWT component therefore the SWT Event Dispatcher is started before the UI appears and can conflict with AWT.

I guess a workaround to this bug which could be used for "urgency situation" (e.g. teaching room) would be to disable the splash screen on the target machine. On MAC OS X: open the file "[$HOME]/.txm/TXM.ini" and insert the following line at the top of the file:

-nosplash

If someone having this bug could confirm this workaround works, it would help us to fix this issue.

#24 Updated by Serge Heiden over 4 years ago

This issue is maybe related to the '-XstartOnFirstThread' option to start a JVM on Mac OS X and the fact that It's well known that osx requires the swt library to run in the main thread (see all the related questions on Stackoverflow) ?

#25 Updated by Sebastien Jacquot over 4 years ago

I think too it's strongly linked to this arg but at this moment I never managed to run TXM without this argument with Cocoa, log:

...
***WARNING: Display must be created on main thread due to Cocoa restrictions.
...
org.eclipse.swt.SWTException: Invalid thread access
    at org.eclipse.swt.SWT.error(SWT.java:4441)
...

Actually, this argument is necessary on Cocoa to say to AWT to not start its Event loop thread but waiting for SWT to run it. See comments in http://bugs.java.com/view_bug.do?bug_id=8019496

#26 Updated by Serge Heiden over 4 years ago

The '-XstartOnFirstThread' option seems mandatory to run SWT in a JVM on Mac OS X (with Cocoa/AppKit-based AWT), see for example http://mail.openjdk.java.net/pipermail/bsd-port-dev/2008-December/000173.html.

This only means that we are not completely free to deal with thread management during TXM initialization on Mac OS X. This is just a warning, not a conclusion of any sort.

#27 Updated by Sebastien Jacquot over 4 years ago

That's what I read too.
New test with tiny test case but now with the '-XstartOnFirstThread' argument:
OS X: the thread called AWT-AppKit is NOT started if AWT is not used in the source code

#28 Updated by Sebastien Jacquot over 4 years ago

Since we can not reproduce this bug (I kept trying but still didn't manage), before we consider trying to fix this issue I propose to release the next alpha/beta (stable?) as is. Then if we find a machine where this bug occurs, try to dump the JVM threads stack to get more information, e.g. using "jstack -l pid" or if needed force full stack trace with "jstack -l -F pid". The pid of TXM can be found with the "jps" command.
We can also use VisualVM to get some other informations.

I summarize here the workarounds which may "temporary fix" the issue:
- do not start the splash screen, see https://forge.cbp.ens-lyon.fr/redmine/issues/894#note-22
- if the bug is linked to AWT/JFC charts engine, starting TXM with R charts engine should not hang up. So we can edit "org.txm.rcpapplication.prefs" to force the R/SVG mode, then run TXM, the 2 involved parameters/lines should be replaced as following:

charts_engine_name=r_charts_engine
charts_engine_output_format=svg

Once it launched, use the parameters UI entry to switch back to JFC charts engine.

#29 Updated by Sebastien Jacquot over 4 years ago

After reading http://bugs.java.com/view_bug.do?bug_id=8019496 and http://bugs.java.com/view_bug.do?bug_id=8065709, the freeze may also be linked to the /org.txm.toolbox/src/java/org/txm/utils/logger/Log.java class. But here too, I don't think this class is used while splash screen initialization ?

#30 Updated by Sebastien Jacquot over 4 years ago

  • Description updated (diff)

#31 Updated by Sebastien Jacquot over 4 years ago

  • Description updated (diff)

#32 Updated by Sebastien Jacquot over 4 years ago

  • Description updated (diff)

#33 Updated by Matthieu Decorde about 4 years ago

  • Description updated (diff)

#34 Updated by Matthieu Decorde about 4 years ago

  • Description updated (diff)

#35 Updated by Sebastien Jacquot about 4 years ago

I think we can close this issue.
The first AWT calls (appearing during the TBX initialization) are now done in the SWT UI main thread. The TBX initialization is now done in an SWT ProgressDialog UI thread, displaying "Loading corpora" at start up. Some improvements may need to be done to the dialog process, see #1297.

#36 Updated by Matthieu Decorde about 4 years ago

  • Description updated (diff)

#37 Updated by Sebastien Jacquot about 3 years ago

  • Status changed from Feedback to Closed
  • % Done changed from 80 to 100

Also available in: Atom PDF