SIGSEGV when closing JOGL applications

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):

#
# A fatal error has been detected by the Java Runtime Environment:
#
#  SIGSEGV (0xb) at pc=0x00007fecb888bc98, pid=1966, tid=140654704224016
#
# 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
#
# If you would like to submit a bug report, please visit:
#   http://java.sun.com/webapps/bugreport/crash.jsp
#

---------------  S Y S T E M  ---------------

OS:squeeze/sid

uname:Linux 2.6.32-22-generic #33-Ubuntu SMP Wed Apr 28 13:28:05 UTC 2010 x86_64
libc:glibc 2.11.1 NPTL 2.11.1
rlimit: STACK 8192k, CORE 0k, NPROC infinity, NOFILE 1024, AS infinity
load average:0.79 0.77 0.56

CPU:total 4 (8 cores per cpu, 2 threads per core) family 6 model 37 stepping 2, cmov, cx8, fxsr, mmx, sse, sse2, sse3, ssse3, sse4.1, sse4.2, popcnt, ht

Memory: 4k page, physical 3976320k(1043116k free), swap 8385888k(8385888k free)

vm_info: Java HotSpot(TM) 64-Bit Server VM (16.3-b01) for linux-amd64 JRE (1.6.0_20-b02), built on Apr 12 2010 13:57:11 by "java_re" with gcc 3.2.2 (SuSE Linux)

time: Mon Jun  7 13:52:40 2010
elapsed time: 298 seconds


This happens with other user's applications as well, so I don't think I'm doing anything strange in my programs that would be causing this. I haven't seen this error in other versions of Ubuntu or Windows. I'm using Sun's Java. Any idea what might be going on here?

----------------

JOGL version: jsr-231-2.0-beta10
GPU: ATI HD Mobility 5850 (using proprietary FGLRX / Catalyst 10.5 drivers)


Thanks

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

On 06/15/2010 02:47 AM, Sven Gothel [via jogamp] wrote: + JOGL version / or build :)

regards,
michael

Thank you Sven and Michael,

I've added the JOGL version and GPU info to my original post:
GPU: ATI HD Mobility 5850 w/ proprietary Catalyst 10.5 drivers
JOGL: jsr231-2.0-beta10

It seems like a fairly harmless bug then; thanks for the detailed response. The primary reason I inquired is because I'm hosting my projects on a repository and sometimes I commit without remembering to delete the log files. They're also added to my Eclipse workspace, so it gets a little cluttered after testing for a bit. If you know of an easy way to disable the output that might be useful temporarily, but I can probably deal with it for now.

Thanks again,
Justin