---- Reported by robnugent 2004-12-08 03:34:59 ---- I have a simply JOGL testcase that results in a SIGSEGV in the following environment: *) Athlon 1800+ *) NVIDIA Geforce FX5200 *) Linux Fedora Core 3 Kernel 2.6.9-1.681_FC3 *) NVIDIA driver 1.0.6629 *) JDK 1.5.0 *) JOGL 1.0b7 The testcase dows nothing other than start an Animator and then attempts to cleanly stop that Animator and close down cleanly by hiding and disposing the JFrame. Run the simple testcase contained in http://195.137.38.88/jogl/testcaseTest.java Once the display method has started to be called, manually close the window. *Some* of the time this results in a SIGSEGV during the call to the dispose() method on the JFrame. This happens infrequently, but seems to occur most reliably immediately after a reboot. The SIGSEGV can been seen in http://195.137.38.88/jogl/testcase/hs_err_pid3363.log ---- Additional Comments From robnugent 2004-12-08 03:36:01 ---- Created an attachment Simple test case ---- Additional Comments From robnugent 2004-12-08 03:37:54 ---- Created an attachment hotspot error log ---- Additional Comments From robnugent 2004-12-08 03:40:11 ---- Testcases/hotspot log also attached to this testcase. URL for testcase should have read: http://195.137.38.88/jogl/testcase/Test.java ---- Additional Comments From robnugent 2004-12-08 03:42:46 ---- I typoed the JOGL level also: it should read 1.1b7 ---- Additional Comments From ssylvis 2005-01-06 18:45:26 ---- I am also having this issue. I am running: - Linux Red Hat 9 - NVidia Quadro4 750 XGL, with drivers 66.29 - JDK 1.4.2 - Jogl 1.1b07 The attached (JoglSimpleTest) test case always duplicates the issue on my machine when the frame is manually closed. (I've also attached the exception log as JoglSimpleTest-exception.log.) The issue appears to be reduced to when the Jogl GLCanvas is removed from the parent frame. In the test case, the exception is thrown when the frame dispose() method is called. The removeNotify() method of GLCanvas is then called, which eventually calls GLContext destroyImpl() and the exception is thrown when glXDestroyContext() is called in X11GLContext. Sean ---- Additional Comments From ssylvis 2005-01-06 18:46:51 ---- Created an attachment Test case file ---- Additional Comments From ssylvis 2005-01-06 18:48:12 ---- Created an attachment Exception log ---- Additional Comments From kbr 2005-02-23 15:42:20 ---- This appears to be a driver bug. As far as I can tell all of the necessary synchronization is in place in the JOGL library and the only issue is that the OpenGL context is being destroyed on a different thread than the one on which it was created and drawn to. Specifying -DJOGL_SINGLE_THREADED_WORKAROUND=true makes the crash disappear on my Linux box (RHAS 2.1, NVidia GeForce FX 5800, 66.29 drivers). I don't see a crash on Solaris, so it isn't a bug seen on all X11 platforms. I would recommend you send your test case to NVidia and ask them to test it with the latest version of JOGL. ---- Additional Comments From kbr 2005-02-24 15:04:02 ---- Stability problems have been reported on all three of JOGL's major supported platforms (Windows, Linux and Mac OS X) whose root cause is multithreading-related bugs in vendors' OpenGL drivers. On Windows, the most recent version of NVidia's drivers (66.93) when run on a GeForce 6800 causes a blue screen of death upon exit from the simplest JOGL demo (Gears). On Linux, JVM crashes have been reported upon exit of certain test cases on NVidia hardware. The same test case causes a report of an unexpected async reply from Xlib on ATI hardware (at the last time of testing -- I no longer have access to a Linux machine with ATI hardware because all of their currently available drivers crash the X server on my machine). On Mac OS X, low-level warnings from Cocoa are printed in multithreaded JOGL situations which can lead to JVM crashes. All of these problems' root cause is that the current OpenGL drivers on the market, or supporting software built on them, were not designed to be used in a multithreaded fashion. Most C programs which use OpenGL are either single-threaded or perform all of their OpenGL work from a single thread. JOGL was originally designed to support OpenGL rendering from arbitrary threads and appropriate synchronization was introduced into the library to handle this. However, we have had to scale back this support as stability issues have been encountered. The most recent round of reported bugs, including the PC crash upon exit of the JOGL demos, is serious enough that we must take drastic measures. Support was introduced in earlier JOGL releases to move all of the OpenGL work performed by JOGL and users' code via the GLEventListener on to the AWT event dispatch thread. It turns out that doing this works around all of the above reported bugs. In JOGL 1.1 b08 and 1.1 b09, code changes were made to make this single-threaded support more correct; this checkin includes another small set of such changes, including some to the GLPbuffer implementation, and changes the default of the flag controlling this support to true. -Djogl.1thread=true is now the default. -Djogl.1thread=auto restores the behavior of previous releases, which was to enable the single-threaded mode only with ATI cards. This auto-detection mechanism was not robust enough and adding cases for the crashes above was not feasible. -Djogl.1thread=false disables the single-threaded workaround. Older synonyms for this system property, JOGL_SINGLE_THREADED_WORKAROUND and ATI_WORKAROUND, remain in the source base for the time being. Changing the value of any of these system properties is not recommended. The expected performance impact of these changes is minimal. In earlier JOGL releases it appeared that the overhead of making a context current and releasing it each frame was very significant and a key differentiator in being able to match C performance. More recent tests seem to indicate that this is no longer the case, at least with current hardware. Regardless, we must achieve stability in order for the library to be useful and this seems to be the best means of achieving that goal. We believe that the compatibility impact of these changes for existing JOGL applications will also be minimal. For correctly-written JOGL applications, the only visible change in behavior should be that the values of thread-local variables accessed through the java.lang.ThreadLocal class may change since the actual thread on which the GLEventListener's callbacks will be executed may have changed. Multithreaded JOGL applications performing complex inter-thread synchronization may see subtle differences in behavior. We hope that such applications and the developers writing them will be able to handle this change in behavior without much trouble. We will continue to work with graphics card vendors to improve the stability of their OpenGL drivers. Until that happens, we believe this change will yield the best possible improvement in stability and portability for applications using JOGL. --- Bug imported by sgothel@jausoft.com 2010-03-24 07:47 EDT --- This bug was previously known as _bug_ 124 at https://jogl.dev.java.net/bugs/show_bug.cgi?id=124 Imported an attachment (id=29) Imported an attachment (id=30) Imported an attachment (id=31) Imported an attachment (id=32) The original submitter of attachment 29 [details] is unknown. Reassigning to the person who moved it here: sgothel@jausoft.com. The original submitter of attachment 30 [details] is unknown. Reassigning to the person who moved it here: sgothel@jausoft.com. The original submitter of attachment 31 [details] is unknown. Reassigning to the person who moved it here: sgothel@jausoft.com. The original submitter of attachment 32 [details] is unknown. Reassigning to the person who moved it here: sgothel@jausoft.com.