Crash on Macos using Java 9

Hi

Java3D 1.6.0 relies on JOGL 2.3.2, the latter needs some complementary settings to work correctly with Java 1.9:
https://jogamp.org/bugzilla/show_bug.cgi?id=1317#c9

 I added --add-exports=java.desktop/sun.java2d=ALL-UNNAMED which I did not have originally, but unfortunately it did not help and the application still crashes under the same conditions (mac OS, java 9...).
This is a link to the application that I am working on which relies extensively on java3d:
https://sscweb.gsfc.nasa.gov/tipsod/

Your help is greatly appreciated

Please be more accurate and post the full stack trace. Which version of OS X do you use?

Keep in mind that this problem might be caused by a bug in AWT under OS X with a specific version.

P.S: Please try with Java 1.8.

(1) The  mac Version is : macOS Sierra (Version 10.12.6)

(2) The stack trace is  at (for the next 10 days) :
https://opendrive.gsfc.nasa.gov/shortauth/r/NQei9Oyb

(3) The application works with java 8 on all platforms including this mac

Thanks. I know that it's unpleasant but since Oracle bought Java, we usually have to wait for some months to get a really "stable" major version. I still use Java 1.8 in production and I won't switch before 2019. We'll have to revisit this problem later.

Hi All,

My application (http://ffx.biochem.uiowa.edu) uses Java3D 1.6.0 / JOGL 2.3.2 and was also crashing on Mac OS X under JDK9.

I swapped in Doug Lyon's build of J3D / JOGL (from here http://show.docjava.com/book/cgij/code/jnlp/libs/jogl) and this did the trick!

Thanks to Doug! And thanks to the JogAmp and Java3D developers for all your work.

- Mike

It's dangerous, it's not a reliable solution, please stop using the forum to advertise this kind of "trick". The real solution consists in fixing the release of some resources that causes a crash under OS X + Java 1.9. The "trick" works around the real bug and has some nasty side effects, someone will complain about an abnormal high memory footprint... The fact that you don't see the problem in your particular case doesn't mean that it doesn't exist.

I advise you to switch back to the official build in production. Promoting a low quality workaround and encouraging people to use an unofficial self-made build not only for testing purposes don't help the community. Doug Lyon's build should be used only for test.

P.S: Doug Lyon's build doesn't contain a fix of mine affecting some GNU Linux users. You have what you deserve :)

Hi Julien,

The degree of negativity in your response seems a bit unnecessary - ‘You have what you deserve’?. I was clearly trying to be helpful and thank Java3D maintainers such as yourself.

The ‘official’ builds of Java3d 1.6.0 and JOGL 2.3.2 cause my application to crash on Mac OS X under JDK 9, while Doug’s build works. Thus, advising me switch back to the official version is not very helpful if I want to explore using JDK 9 or JDK 10 features.

Perhaps you could suggest when the official J3D / JOGL releases will incorporate a fix to the ‘real bug’?

Thanks,
- Mike

Hey

In my humble opinion, Doug's build was useful only to confirm the root cause of the bug and should not be used in production as it may cause a memory leak in the native memory (not in the Java heap). That's why encouraging anyone to use his build is a very bad idea. If many developers use his build, discover an abnormal memory footprint and point out Java3D, it will harm our efforts and some people won't be smart enough to make the distinction between his unofficial build and the official build of Java3D 1.6.0-Final.

You want to use his build to work around a bug with Java 1.9 and OS X but then, you don't use another JAR not provided by Doug with a fix for a bug affecting some Linux users. When JOGL 2.3.3 is released, some developers will go on using the already obsolete JARs provided by Doug. If you really want to use Java 1.9 and 1.10 features not in production only to "explore", why not using another operating system? If it's just for development, what is wrong with that? If you don't absolutely need some Java 1.9 and 1.10 features, you can still ship your software with Java 1.8 and avoid relying on the JRE installed on the system.

It's a JOGL bug for sure. I know where the crash happens in the native code but I haven't found a fix yet and I have no Mac which doesn't help at all for a platform specific bug. What is really frustrating is that some developers who claimed to be willing to contribute content themselves with a dirty workaround with an highly probable nasty side effect and claimed to have fixed the bug whereas it's plain wrong and they could have spent a few days to investigate with me so that we fix the real bug once for all. All this only adds some confusion in the community. To make things clear, if they had provided a clean bug fix, we would have had accepted it.

The help of a developer under OS X is warmly welcome. Keep in mind that we are volunteers. The bug report is here:
https://jogamp.org/bugzilla/show_bug.cgi?id=1317

By the way, if you reproduce the crash under Java 1.10, please can you post the logs?

We are seeing the JRE crash with java 3D 1.6.0 pre11 and Java 10. If we upgraded to 1.6.0 final or 1.7.0, might that solve the issue, or should we expect this to occur with those versions of Java3D and Java 9+.

I've posted the log in case its useful. https://www.dropbox.com/s/wahjzrpxn1opz4p/hs_err_pid80135.log?dl=0

For what its worth, I did try: java -jar jogamp-fat-test.jar and that seems to work as expected.

thanks,

Nick

Thank you for the logs.

Please upgrade at least to Java3D 1.6.0-Final because we won't backport our bug fixes into older versions and the next fixes will be done in Java3D 1.7.0.

This issue isn't solved yet. Please use Java 1.8 in the meantime.

I remind that there is no "long term support" version for Java3D, we only maintain the very latest version. Using obsolete versions in production is clearly a bad idea.

Julien,
I'm a bit lost on this bug.

Java3D on jre1.9 an 1.10 both work on windows, but are currently failing on OSX. Unfortunately I'm getting a server error trying to access the bugzilla entry you refer to above. I don't have a Mac to run this on and investigate.

The crash log Nick provided doesn't give me any clues about how to investigate this issue.

Do you have the original bugzilla details? Can you post them here?

I know that the Sweet Home 3D and ImageJ guys are going to be interested in getting this problem solved at some point in the near future, so if I can get a bit of a test case together I'm sure they'll run it on a Mac and give more information about what the issue is.

Thanks,
Phil.

Hey

Nick ran the test, it seems to show that the bug doesn't come from JogAmp unlike what I thought but it's only true if he ensured to run it with Java >= 1.9. Nick, please can you post the logs of the working test?

As I said, I thought the problem came from JogAmp itself when releasing the native resources (the context and the display) with the latest version of OS X and Java >= 1.9.

Nick, please can you run this rudimentary example?
https://jogamp.org/wiki/index.php/Rudimentary_standalone_example_using_the_fixed_pipeline_by_Julien_Gouesse

If it doesn't crash when you close the window, it means that JogAmp isn't to blame and that the problem comes from Java3D.

I ran the JOGLQuadExample under Java 10.

iMac:Downloads nick$ java --version
java 10.0.1 2018-04-17
Java(TM) SE Runtime Environment 18.3 (build 10.0.1+10)
Java HotSpot(TM) 64-Bit Server VM 18.3 (build 10.0.1+10, mixed mode)


If I quit it, using command-Q (Apple's standard app quit) then I don't get any error. If I close the window explicitly then I get the JRE crash

I've put the log for that here:

https://www.dropbox.com/s/p2g39jvuhf235eu/hs_err_pid10822.log?dl=0'

I tried 'java -jar jogamp-fat-test.jar' again, I don't get a JRE crash in either case. However, if I try to close the window, it goes blank and hangs and I have to force quit. If I quit with  command-Q, I get:

Exception in thread "main-AWTAnimator#00" com.jogamp.opengl.util.AnimatorBase$UncaughtAnimatorException: com.jogamp.opengl.GLException: Caught ThreadDeath: null on thread main-AWTAnimator#00
        at com.jogamp.opengl.util.AWTAnimatorImpl.display(AWTAnimatorImpl.java:92)
        at com.jogamp.opengl.util.AnimatorBase.display(AnimatorBase.java:452)
        at com.jogamp.opengl.util.Animator$MainLoop.run(Animator.java:204)
        at java.base/java.lang.Thread.run(Thread.java:844)
Caused by: com.jogamp.opengl.GLException: Caught ThreadDeath: null on thread main-AWTAnimator#00
        at com.jogamp.opengl.GLException.newGLException(GLException.java:76)
        at jogamp.opengl.GLDrawableHelper.invokeGLImpl(GLDrawableHelper.java:1327)
        at jogamp.opengl.GLDrawableHelper.invokeGL(GLDrawableHelper.java:1147)
        at com.jogamp.newt.opengl.GLWindow.display(GLWindow.java:759)
        at com.jogamp.opengl.util.AWTAnimatorImpl.display(AWTAnimatorImpl.java:81)
        ... 3 more
Caused by: java.lang.ThreadDeath
        at java.base/java.lang.Thread.stop(Thread.java:949)
        at com.jogamp.newt.opengl.GLWindow$GLLifecycleHook$1.run(GLWindow.java:724)
        at java.base/java.security.AccessController.doPrivileged(Native Method)
        at com.jogamp.newt.opengl.GLWindow$GLLifecycleHook.shutdownRenderingAction(GLWindow.java:719)
        at jogamp.newt.WindowImpl.shutdown(WindowImpl.java:635)
        at jogamp.newt.WindowImpl.shutdownAll(WindowImpl.java:123)
        at jogamp.newt.DisplayImpl$1.run(DisplayImpl.java:74)
        at com.jogamp.nativewindow.NativeWindowFactory.shutdown(NativeWindowFactory.java:272)
        at com.jogamp.nativewindow.NativeWindowFactory$2$1.run(NativeWindowFactory.java:190)
        ... 1 more


Hope this helps.

If I could get the details of the bug report, I could probably look into this further. Thanks.

Nick

Thank you. Your logs confirm that the problem comes from JOGL, when releasing the context:
Event: 7.964 Thread 0x00007fb1dab0b800 Uncommon trap: reason=unstable_if action=reinterpret pc=0x000000011c2197e8 method=jogamp.opengl.GLContextImpl.release(Z)V @ 161 c2

Java 11 was released a week ago and this 1 year old blocking bug isn't fixed yet
Beside a computer to run tests, what do JOGL team miss to fix it?