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

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 u 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

(from redmine: issue id 894, created on 2014/07/01 by Matthieu Decorde)

added 1 deleted label

changed milestone to %TXM 0.7.7

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

(from redmine: written on 2014/07/02 by Sebastien Jacquot)

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

(from redmine: written on 2014/07/02 by Sebastien Jacquot)

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

(from redmine: written on 2014/07/02 by Sebastien Jacquot)

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.

(from redmine: written on 2014/07/03 by Sebastien Jacquot)

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.

(from redmine: written on 2014/07/03 by Sebastien Jacquot)

Beta tested

(from redmine: written on 2014/07/17 by Matthieu Decorde)

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.

(from redmine: written on 2014/11/04 by Sebastien Jacquot)

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

(from redmine: written on 2014/11/28 by Matthieu Decorde)

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 loo

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())

(from redmine: written on 2015/01/09 by Sebastien Jacquot)

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.

(from redmine: written on 2015/01/13 by Sebastien Jacquot)

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.

(from redmine: written on 2015/01/13 by Sebastien Jacquot)

Also see the property: -Djava.awt.headless=true
http://www.oracle.com/technetwork/articles/javase/headless-136834.html

(from redmine: written on 2015/01/13 by Sebastien Jacquot)

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) ?

(from redmine: written on 2015/01/13 by Serge Heiden)

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

(from redmine: written on 2015/01/13 by Sebastien Jacquot)

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.

(from redmine: written on 2015/01/13 by Serge Heiden)

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

(from redmine: written on 2015/01/13 by Sebastien Jacquot)

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.cbens-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 u 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.

(from redmine: written on 2015/01/13 by Sebastien Jacquot)

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 ?

(from redmine: written on 2015/01/14 by Sebastien Jacquot)

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 u Some improvements may need to be done to the dialog process, see #1297.

(from redmine: written on 2015/04/02 by Sebastien Jacquot)

closed

assigned to @sjacquot

added type::bug label

added startup label

added priority::urgent label