Posted by Sven Gothel on Jun 15, 2010; 12:47am
URL: https://forum.jogamp.org/SIGSEGV-when-closing-JOGL-applications-tp895912p895995.html

On Tuesday, June 15, 2010 01:40:57 Justin [via jogamp] wrote:
>
> Hi all,
>
> I've been developing with JOGL for a little over a year now, but I've
> started having an annoying bug when I upgraded to Ubuntu 10.04 recently.
> JOGL programs work fine, but whenever I close them down I get a SIGSEGV
> error and a .log file is generated with some extra info. Here's an example
> (top/bottom parts of message for brevity):
>

http://jogamp.org/wiki/index.php/Jogl_FAQ#Bugreports_.26_Testing

Hi Justin,

you almost did a complete bugreport, thank you :)

(You missed to name GPU and drivers ..)

I assume you use an AMD/ATI GPU with their proprietary driver ..

I use quite the same setup and my 'exception' is (almost identical to yours):

#
# A fatal error has been detected by the Java Runtime Environment:
#
#  SIGSEGV (0xb) at pc=0x00007ffd242bec98, pid=25713, tid=140725230016272
#
# JRE version: 6.0_20-b02
# Java VM: Java HotSpot(TM) 64-Bit Server VM (16.3-b01 mixed mode linux-amd64 )
# Problematic frame:
# C  [libX11.so.6+0x37c98]  XQueryExtension+0x28
#
# An error report file with more information is saved as:
# /usr/local/projects/JOGL/jogl/make/hs_err_pid25713.log
#
# If you would like to submit a bug report, please visit:
#   http://java.sun.com/webapps/bugreport/crash.jsp
#

/usr/local/projects/JOGL/jogl/make/hs_err_pid25713.log

says somewhere in the middle:

        VM state:at safepoint (shutting down)

Also notice: No java threads are running anymore!

So, we decided to 'ignore' this SEGV thingy until further investigation,
however, it has something to do with X11 and multithreading.

We use 'XInitThreads()' to setup X11 multithreading support
and it seems that the [J]AWT implementation in the JVM calls
X11 functions before and after JOGL runs.

The lack of calling 'XInitThreads()' in the JVM/JRE (when using AWT)
is already identified as a huge pain and a workaround for this
does not seem to be a good idea at all(*).

The best solution would be to convince Oracle/OpenJDK to issue
the XInitThread() call ASAP (before any other X11 call),
and to revisit some _global_ AWT locks, since they are probably no more necessary.
This would allow true inter-component multithreading with X11
without the need of a global AWT toolkit lock and hence
a fluent X11 workflow where threads won't disturb each other anymore.

BTW .. without XInitThreads() and with XLockDisplay
it was not possible with the NV driver to manage lifecycle operations
(create, makecurrent/release, destroy) in a reliable manner across threads.
Eg:
  thread1: createContext, makeCurrent, some-rendering, release ..
  thread1: stops
  thread2: makeCurrent/release, destroyContext
           -> hangs somewhere, ie makeCurrent, swapBuffer or destroy

So .. we have to think about this, and triage this in more detail.

Multithreading in JOGL is not about using multiple rendering threads
here, but to allow multiple threads to use the same X11 Display connection
for rendering and event dispatching undisturbed, read: non blocking.

For now, all I can say is, don't worry about this message,
it ain't even considered a failure/error with the junit tests.

~Sven

(*) Eg using a global lock (let it be awtlock or X11 DisplayLock)
would render fluent event processing and GL rendering impossible.
Using a new display connections for each 'window/drawable' would render
GL context sharing impossible.


--
health & wealth
mailto:[hidden email] ; http://jausoft.com
land : +49 (471) 4707742 ; cell: +49 (151) 28145941
Timezone CET: PST+9, EST+6, UTC+1