Bug 548 - Some MacOS X Machines freeze at JOGL initialization, some even crash
Summary: Some MacOS X Machines freeze at JOGL initialization, some even crash
Alias: None
Product: Jogl
Classification: JogAmp
Component: macosx (show other bugs)
Version: 2
Hardware: pc_x86_64 macosx
: P3 major
Assignee: Sven Gothel
Depends on: 533
  Show dependency treegraph
Reported: 2012-01-04 08:12 CET by Sven Gothel
Modified: 2013-10-03 19:16 CEST (History)
2 users (show)

See Also:
Type: ---
SCM Refs:
e702a9401d4564c970ddda71116d14d7661dd048 835b36d626f75f9e96001a41c2a6fe9f90466ae1 ffcf0cb5beaf3c7c363d45cef0b9d18dcf3f50c6 b05ccd62d28bcdc320fd35094f2d278b16743eab
Workaround: ---


Note You need to log in before you can comment on or make changes to this bug.
Description Sven Gothel 2012-01-04 08:12:20 CET
Continuing analyzing bug 533 and considering reports from the forum



None of the test applets from the following page work on my Mac.


Launching the test applications is associated with few seconds of absolute
unresponsiveness of the whole computer - something that I have not
experienced on this computer before. The Java Console pops up at first but
then whole java process crashes/disappears without any message.

The only test that launched successfully after the few seconds of
unresponsiveness is "JOGL Version Information" . The output is provided

Java Web Start 1.6.0_26
Using JRE version 1.6.0_26-b03-384-10M3425 Java HotSpot(TM) 64-Bit Server VM

Platform: MACOS / Mac OS X 10.6.8 (os), x86_64 (arch) 24 cores
MachineDescription: runtimeValidated true, littleEndian true, 32Bit false,
primitive size / alignment:
  int8    1 / 1, int16   2 / 2
  int     4 / 4, long    8 / 8
  int32   4 / 4, int64   8 / 8
  float   4 / 4, double  8 / 8, ldouble 16 / 16
  pointer 8 / 8, page    4096
Platform: Java Version: 1.6.0_26, VM: Java HotSpot(TM) 64-Bit Server VM,
Runtime: Java(TM) SE Runtime Environment
Platform: Java Vendor: Apple Inc., http://www.apple.com/, is JavaSE: true


Wade Walker:
I get the same results in OS X Lion 10.7.1 (on a MacBook Air with NVIDIA
GeForce 320M). 


Sven Gothel:

Ok, so here we have the 'freeze' problem on 10.6.8 _and_ 10.7.1,
where the latter seems to be 'new'.

Pls check your OSX 'Console' for the messages:
  NVDA(OpenGL): Channel exception! exception type = 0xd = GR: SW Notify Error
  NVDA(OpenGL): Channel timeout!

If the above happens, .. I have no clue whats causing it 
from the JOGL side. However, Apple/NV reply to this generic/general 
known issue here (send back machine (RMA) to repair):

This happens with my old MBP as well, but I am very surprised this happens
with Wade's MacBook Air and the relative new NV 320M.
I guess the NV hardware issue was about some silicon heat/stress and cracks
reported a long time ago around 2008 or so (semiaccurate.com, search for 'bumpgate'):

But ofc I am not sure. All I know is that I have tried several different initialization sequences
while working on bug 533  on my defective MBP and nothing helped.
Sometime (cold boot) .. no freeze appears at first, but later on the freeze appears.

So the new additional behavior on your machine(s) are:
  - JOGL crashes after the freeze
  - freeze/crash happens on more modern NV 320M MB-Air

Comment 1 Sven Gothel 2012-01-04 10:07:39 CET
My working machine (it's also our Jenkins node):
  - Mac Mini
  - Mac OS X 10.7.2
  - Intel Core 2 Duo
  - NV Geforce 320M 256MB
    - Vendor 0x10de (NV), Device 0x08a4, Revision 0x00a2
    - Rom 3546
    - Driver NVIDIA-7.12.9
Comment 2 Sven Gothel 2012-01-09 09:27:43 CET
Ok, looks like I found the commits responsible for the 'freeze':

jogl-b543-2011-10-25_06-11-39 + gluegen-b429-2011-10-24_11-48-05 OK

jogl-b544-2011-10-27_05-06-32 + gluegen-b431-2011-10-27_05-00-52 FREEZE

ChangeSet for jogl build 544: https://jogamp.org/chuck/job/jogl/544/

Looks like it's commit f326119fd60eb3a851317bbed5bd57a535816014

Digging in to it now ..
Comment 3 Sven Gothel 2012-01-09 13:55:46 CET
The new code of commit f326119fd60eb3a851317bbed5bd57a535816014,
MacOSXCGLDrawableFactory.isOSXContextAvailable() triggered an NVidia driver bug.

The new functions leads to available GL profile probing, ie a very fast context creation, makeCurrent(),
release(), destroy() sequence w/o swapBuffers() or glFinish() - hence no explicit sync of the GL pipeline.

Adding a glFinish() before actually releasing the GL context solves this problem
of the NV bug.

Comment 4 Sven Gothel 2012-01-12 21:25:06 CET
reopened: still regressions on 10.6 - 10.6.2 (<10.6.8?) at initialization,
culprit is the pixelformat.
Comment 5 Sven Gothel 2012-01-13 00:22:37 CET
    OSX Fixes: bug 548 (another regression: pixelfmt), ctx creation failure -> no exception,
    - bug 548: Another regression: pixelfmt failed for 10.6.7 and/or software OpenGL
      - enforcing accelerated leads to no pixelformat,
      - using the NSOpenGLView defaultPixelFormat causes to SIGSEGV
    - ctx creation failure shall just lead to return null, no immediate exception
Comment 6 Sven Gothel 2013-02-21 11:07:02 CET

Added GLRendererQuirk for this OSX < 10.7.3 NVIDIA glFLush case
Comment 7 Sven Gothel 2013-10-03 19:16:45 CEST
GLRendererQuirks.GLFlushBeforeRelease is needed 
on OSX < 10.7.3 w/ NV GPU

Was comparing against 1.7.3 instead 10.7.3 !

.. where are the reviews ..