Infrequent crash on OSX 10.8.5 using Java7 and Java3D 1.6

Hi,

An immense thank you to everyone involved with Java3D 1.6.0 release! Everything is working great except
I'm having a hard-to-reproduce, infrequent crash when attempting to update a JSplitPane with a container which
ultimately contains a newly created Canvas3D.  Here is the stack of the crashed thread (outside the JVM):


Thread 0 Crashed:: AppKit Thread  Dispatch queue: com.apple.main-thread
0   libsystem_kernel.dylib         0x00007fff8c859212 __pthread_kill + 10
1   libsystem_c.dylib             0x00007fff8945fb24 pthread_kill + 90
2   libsystem_c.dylib             0x00007fff894a3f61 abort + 143
3   libjvm.dylib                   0x0000000106ca0ba3 os::abort(bool) + 25
4   libjvm.dylib                   0x0000000106dab230 VMError::report_and_die() + 2316
5   libjvm.dylib                   0x0000000106ca253d JVM_handle_bsd_signal + 1083
6   libsystem_c.dylib             0x00007fff8944c90a _sigtramp + 26
7   com.apple.opengl               0x00007fff8d510fff CGLReleaseContext + 26
8   com.apple.QuartzCore           0x00007fff8d2ece63 CAOpenGLLayerDestroy(CAOpenGLLayer*, bool) + 73
9   com.apple.QuartzCore           0x00007fff8d2ecefd -[CAOpenGLLayer dealloc] + 25
10  com.apple.AppKit               0x00007fff8490b32c -[NSOpenGLLayer dealloc] + 126
11  libjogl_desktop.jnilib         0x00000001a490609b 0x1a4892000 + 475291
12  libjogl_desktop.jnilib         0x00000001a4905fb6 0x1a4892000 + 475062
13  libjogl_desktop.jnilib         0x00000001a4907aac releaseNSOpenGLLayer + 220
14  libjogl_desktop.jnilib         0x00000001a4908b9d Java_jogamp_opengl_macosx_cgl_CGL_releaseNSOpenGLLayerImpl__J + 29
15  ???                           0x00000001074c1738 0 + 4417394488
16  ???                           0x00000001074b5058 0 + 4417343576
17  ???                           0x00000001074b5058 0 + 4417343576
18  ???                           0x00000001074b5706 0 + 4417345286
19  ???                           0x00000001074af4e7 0 + 4417320167
20  libjvm.dylib                   0x0000000106b5cbb0 JavaCalls::call_helper(JavaValue*, methodHandle*, JavaCallArguments*, Thread*) + 554
21  libjvm.dylib                   0x0000000106b5c980 JavaCalls::call(JavaValue*, methodHandle, JavaCallArguments*, Thread*) + 40
22  libjvm.dylib                   0x0000000106b90425 jni_invoke_nonstatic(JNIEnv_*, JavaValue*, _jobject*, JNICallType, _jmethodID*, JNI_ArgumentPusher*, Thread*) + 698
23  libjvm.dylib                   0x0000000106b83f96 jni_CallVoidMethod + 278
24  libnativewindow_macosx.jnilib 0x00000001960717ae 0x19606c000 + 22446
25  com.apple.Foundation           0x00007fff898a759a __NSThreadPerformPerform + 225
26  com.apple.CoreFoundation       0x00007fff86666b31 __CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE0_PERFORM_FUNCTION__ + 17
27  com.apple.CoreFoundation       0x00007fff86666455 __CFRunLoopDoSources0 + 245
28  com.apple.CoreFoundation       0x00007fff866897f5 __CFRunLoopRun + 789
29  com.apple.CoreFoundation       0x00007fff866890e2 CFRunLoopRunSpecific + 290
30  com.apple.HIToolbox           0x00007fff8bbcfeb4 RunCurrentEventLoopInMode + 209
31  com.apple.HIToolbox           0x00007fff8bbcfc52 ReceiveNextEventCommon + 356
32  com.apple.HIToolbox           0x00007fff8bbcfae3 BlockUntilNextEventMatchingListInMode + 62
33  com.apple.AppKit               0x00007fff8425d533 _DPSNextEvent + 685
34  com.apple.AppKit               0x00007fff8425cdf2 -[NSApplication nextEventMatchingMask:untilDate:inMode:dequeue:] + 128
35  libosxapp.dylib               0x0000000196cdc6f4 -[NSApplicationAWT nextEventMatchingMask:untilDate:inMode:dequeue:] + 124
36  com.apple.AppKit               0x00007fff842541a3 -[NSApplication run] + 517
37  libosxapp.dylib               0x0000000196cdc557 +[NSApplicationAWT runAWTLoopWithApp:] + 156
38  liblwawt.dylib                 0x0000000196c34ba9 -[AWTStarter starter:] + 873
39  com.apple.Foundation           0x00007fff898a759a __NSThreadPerformPerform + 225
40  com.apple.CoreFoundation       0x00007fff86666b31 __CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE0_PERFORM_FUNCTION__ + 17
41  com.apple.CoreFoundation       0x00007fff86666455 __CFRunLoopDoSources0 + 245
42  com.apple.CoreFoundation       0x00007fff866897f5 __CFRunLoopRun + 789
43  com.apple.CoreFoundation       0x00007fff866890e2 CFRunLoopRunSpecific + 290
44  java                           0x00000001067603b0 CreateExecutionEnvironment + 871
45  java                           0x000000010675ab5c JLI_Launch + 1952
46  java                           0x000000010676070d main + 101
47  java                           0x000000010675a3b4 start + 52



The Canvas3D is created on a worker thread but the JSplitPane is updated on the EDT.  Interestingly the crash never
occurs the first time the JSplitPane is modified, only later based on user driven selection of a new thing to display.  As far as I know this never happened using Java6 and the last version of Java3D 1.5.

Tom

Hi

ThomasR wrote

The Canvas3D is created on a worker thread but the JSplitPane is updated on the EDT.  Interestingly the crash never
occurs the first time the JSplitPane is modified, only later based on user driven selection of a new thing to display.  

Don't create a Canvas3D on a worker thread and provide a SSCCE if you want to give us a chance to reproduce your bug.

ThomasR wrote

As far as I know this never happened using Java6 and the last version of Java3D 1.5.

As far as I know, Java3D 1.5.2 doesn't support OS X 10.8.5, that's why there was no chance of reproducing this crash with it.

Thanks very much for your reply:

>Don't create a Canvas3D on a worker thread and provide a SSCCE if you want to give us a chance to reproduce your bug.

Not even on the main thread?  I've done this all the time in the past.  I did try moving the Canvas creation to the
EDT and still the crash.

>As far as I know, Java3D 1.5.2 doesn't support OS X 10.8.5, that's why there was no chance of reproducing this crash with it.

You can run Java3D 1.5.2 on OS X 10.8.5 and later (Mavericks) but you have to use Java6


Tom

Is there any chance of capturing the crashdump from the JVM, any other details you can grab will be helpful.

Harvey

Canvas3D extends java.awt.Canvas, it's not JOGL's fault, manipulate AWT components on AWT EDT if you don't want to have some troubles. Please provide a full test case and some logs. We don't have enough information to help you. Moreover, maybe you'll realize that you did something wrong by trying to reproduce your bug with a very simple example.

That's what I meant, Java3D 1.5.2 has no chance to work with OpenJDK or Oracle Java under OS X 10.8.5. Anyway, this version isn't maintained and shouldn't be used in production.

Hi Harvey,

Here's the complete log file if it helps:

ftp://ftp.ssec.wisc.edu/pub/incoming/hs_err_pid4505.log

Tom

Thanks, I'll try to get around to this soon.

Harvey

Hi Harvey, Julien,

I followed Julien's advice: to create the Canvas3D and update the JSplitPane on the
Swing EDT.  This seems to fix the problem - I haven't been able to crash my application.
I'm not sure if this means "problem solved", but perhaps you can glean some clue and
push this on the back-burner.

Tom

Hi

Thank you very much for the feedback. We should write a Java3D user's guide and mention this kind of limitation even though it comes from AWT. I was able to give you an appropriate advice because you gave me some appropriate pieces of information. This kind of problem concerns JOGL itself, you can crash the JVM when calling GLCanvas.setVisible(true) not on the AWT EDT under Windows with some Intel chips (Intel HD 3000?) and there is nothing we can do to prevent that except reminding developers to manipulate AWT components on the AWT EDT.

Hi Julien,

Looks like I spoke too soon.  The crash is noticeably less frequent, but I think it's now happening on the EDT itself.  The call to OpenGL CGLReleaseContext via libjogl jni Java_jogamp_opengl_macosx_cgl_CGL_releaseNSOpenGLLayerImpl seems to be what's common in all of the crashes.  

The crash never happens the "first time", only when replacement occurs, and then only
when the Canvas3D is created.

I put the full crash dump on our public server:
ftp://ftp.ssec.wisc.edu/pub/incoming/hs_err_pid1101.log

Is it possible for to work backward from this log to develop a workaround?  

Tom

Thank you for the log but we still need a small test case. Moreover, I can't install Oracle Java 1.7 on the only Mac I have :s

Do you reproduce this bug with a plain GLCanvas?

I'm running from the bundled jre from Oracle.  I don't use JOGL directly, only Java3D.  Our system
is pretty complex, we have an abstract api which uses Java3D under the hood so a simple test
cast may not be that realistic, but I'll put something together.  At this point, I think time may be
better spent trying to reuse the Canvas and never replace it, but that will take some refactoring,
and will reduce the generality.

Thanks very much for your feedback!  So strange, can't get it to crash again!

Tom