Client crash 7.9.0


Am getting complete hang of client using global templates, including diagnostics. At time of crash code is producing no errors and resource utilisation etc is normal. Diagnostics hangs at same time.

The template is still very much alpha so is quite crude.

I have attached global template save and a sinle window project that uses the template.

To reproduce fault…run the project in preview and simply mousover the menus. A megamenu popup shoudl appear when you mouseover the buttons.

It all works fine for a while but at some point it just hangs…move your mouse repeatedly over the buttons and for me it crashes in under 30 seconds.

Looking more and more like a bug somewhere in the event execution system.

I removed the diagnostic print statements from the code as these are typically slow operations…and lo and behold I cannot get it to crash anymore.

Could a combination of mouse entered and exited events (eg exited event before completion of entered code for example) be causing a deadlock??

It’s going to be easiest to solve this if you call or email support…

This crash is more prevasive than just the symptoms outlined above.

To reproduce:

Create two identical projects each containing one main window containing one button which executes

system.util.retarget("<insert other project here>")

Now run one of the project and start clicking buttons…it does not take long before the client crashes, can be in as little a 5-6 clicks.

I am on linux, am running server on localhost so there will be no network issues.

UPDATE: Issue only occurs when launching from designer eg Tools->Launch Project staged, or published.

Running project directly (native or weblaunch) works as expected.

Crashed process command via designer

javaws -splash:/usr/share/icedtea-web/javaws_splash.png -Xbootclasspath/a:/usr/share/icedtea-web/netx.jar:/usr/share/icedtea-web/plugin.jar:/usr/share/java/js.jar -Xms8m -Xms32M -Xmx256M -XX:MaxPermSize=128m -Xms32M -Xmx256M -XX:MaxPermSize=128m -Xms32M -Xmx256M -XX:MaxPermSize=128m -classpath /usr/lib/jvm/default-runtime/lib/rt.jar:/usr/lib/jvm/default-runtime/lib/jfxrt.jar -Dicedtea-web.bin.location=/usr/share/icedtea-web/bin/javaws net.sourceforge.jnlp.runtime.Boot -Xnofork localhost:8088/main/system/launch/client/a.jnlp

Non crashing command via web launch

javaws -splash:/usr/share/icedtea-web/javaws_splash.png -Xbootclasspath/a:/usr/share/icedtea-web/netx.jar:/usr/share/icedtea-web/plugin.jar:/usr/share/java/js.jar -Xms8m -Xms32M -Xmx256M -XX:MaxPermSize=128m -Xms32M -Xmx256M -XX:MaxPermSize=128m -Xms32M -Xmx256M -XX:MaxPermSize=128m -classpath /usr/lib/jvm/default-runtime/lib/rt.jar:/usr/lib/jvm/default-runtime/lib/jfxrt.jar -Dicedtea-web.bin.location=/usr/share/icedtea-web/bin/javaws net.sourceforge.jnlp.runtime.Boot -Xnofork /tmp/mozilla_taro0/a-1.jnlp

Only difference is the location to the jnlp.

The jnlp are identical except for the launchts, so no issue here either.

This leaves the designer being the culprit.

This is in a way good news as it means the projects will not be crashing in production.

Workaround for now is not to use the designer for launching during dev.

I’ve had issues with JavaWS on my Mac when I had, unbeknownst to me, a couple of different versions of java floating around. When I used the Native Client Launcher, I had no issues whatsoever. Later I found out the multiple java versions issue, resolved that, and haven’t seen those client crashes return since. Might be worth a little inspection, just in case something similar to this is happening to you.

Recently came across this article, it might be helpful:

In addition to what kcollins said, there are some bugs relating to OSX Accessibility API that may cause application crashes. I run a few 3rd party tools for documentation and key/mouse interaction, and have seen crashes in designer (and clients) sometimes as a result. Java desktop applications aren’t alone in these crashes, but it does seem to happen more often than with native programs.

If in OSX/MacOS, go to System Preferences -> Security & Privacy -> Accessibility. Uncheck items in there and see if the crashing persists.

In my case: BetterTouchTool, Hyperdock, Dash, Discord and Hipchat all seem to contribute to application crashes through accessibility features on occasion. Most people won’t have anything installed that use Accessibility features, and I don’t think I’ve ever seen a production system running on OSX, so this is mostly geared toward developers who may work on a mac.

Get in touch with support if you continue to have issues, as we aren’t familiar with others seeing the particular problem you describe.

The good news is that testing on windows box with single version of java appears to works as expected so it seems issue may be related to my system (arch linux)

I’ll test on some other linux versions and see if the problem is related to my install or linux in general.

Won’t be the first time Java does weird stuff (write once, debug everywhere :slight_smile:)

Related Details:

taro@osiris ~ $ archlinux-java status
Available Java environments:
java-8-openjdk (default)

taro@osiris /usr/lib $ env | grep -i ‘java|jvm’

taro@osiris /usr/lib $ ls -al jvm
total 268
drwxr-xr-x 4 root root 4096 Feb 18 2016 .
drwxr-xr-x 274 root root 258048 Nov 2 07:36 …
lrwxrwxrwx 1 root root 14 Feb 18 2016 default -> java-8-openjdk
lrwxrwxrwx 1 root root 18 Feb 18 2016 default-runtime -> java-8-openjdk/jre
drwxr-xr-x 6 root root 4096 Feb 18 2016 java-7-openjdk
drwxr-xr-x 6 root root 4096 Feb 18 2016 java-8-openjdk

Could also be an openjdk issue. I’ve been much happier since I changed my standard Linux set up routine to wipe out everything openjdk related and install the official Oracle Java. YMMV.