Bug 548

Summary: Some MacOS X Machines freeze at JOGL initialization, some even crash
Product: [JogAmp] Jogl Reporter: Sven Gothel <sgothel>
Component: macosxAssignee: Sven Gothel <sgothel>
Status: RESOLVED FIXED    
Severity: major CC: oherrala, wwalker3
Priority: P3    
Version: 2   
Hardware: pc_x86_64   
OS: macosx   
Type: --- SCM Refs:
e702a9401d4564c970ddda71116d14d7661dd048 835b36d626f75f9e96001a41c2a6fe9f90466ae1 ffcf0cb5beaf3c7c363d45cef0b9d18dcf3f50c6 b05ccd62d28bcdc320fd35094f2d278b16743eab
Workaround: ---
Bug Depends on: 533    
Bug Blocks:    

Description Sven Gothel 2012-01-04 08:12:20 CET 
Continuing analyzing bug 533 and considering reports from the forum
  http://forum.jogamp.org/quot-Test-page-for-JOGL-Applets-quot-do-NOT-work-on-Mac-OS-X-Snow-Leopard-td3622224.html

+++

Jan:
===

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

http://jogamp.org/deployment/jogamp-current/jogl-test-applets.html

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
bellow.

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'.
  https://jogamp.org/bugzilla/show_bug.cgi?id=533

Pls check your OSX 'Console' for the messages:
  NVDA(OpenGL): Channel exception! exception type = 0xd = GR: SW Notify Error
  NVDA(OpenGL): Channel timeout!
https://jogamp.org/bugzilla/show_bug.cgi?id=533#c3

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):
  http://www.insanelymac.com/forum/index.php?showtopic=244227
  http://support.apple.com/kb/TS4088

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'):
  http://semiaccurate.com/2010/10/07/bumpgate-alternative-class-action/

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
                                    gluegen.build.number=429
                                    gluegen.build.id=2011-10-24_11-48-05
                                    gluegen.build.branch=origin/master
                                    gluegen.build.commit=a19f98767da194ba468f53f56c2dcdb9d1d34ac8
                                    jogl.build.number=543
                                    jogl.build.id=2011-10-25_06-11-39
                                    jogl.build.branch=origin/master
                                    jogl.build.commit=4433f2a68fa3ca500e258a6862b0e95461fc5083

jogl-b544-2011-10-27_05-06-32 + gluegen-b431-2011-10-27_05-00-52 FREEZE
                                    gluegen.build.number=431
                                    gluegen.build.id=2011-10-27_05-00-52
                                    gluegen.build.branch=origin/master
                                    gluegen.build.commit=ef30b77fab27262f8b5ef3f98880c0caec30bab5
                                    jogl.build.number=544
                                    jogl.build.id=2011-10-27_05-06-32
                                    jogl.build.branch=origin/master
                                    jogl.build.commit=bc826eb2e216ce82a5e6bc61403e4eff2f338380

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

Looks like it's commit f326119fd60eb3a851317bbed5bd57a535816014
  http://jogamp.org/git/?p=jogl.git;&a=commit&h=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.

http://jogamp.org/git/?p=jogl.git;a=blob;f=src/jogl/classes/jogamp/opengl/macosx/cgl/MacOSXCGLDrawableFactory.java;h=5c726bc54fe3f39d4d8d09d6fa5fda85b11bc90e;hb=5c726bc54fe3f39d4d8d09d6fa5fda85b11bc90e#l138
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 
http://jogamp.org/git/?p=jogl.git;a=commit;h=ffcf0cb5beaf3c7c363d45cef0b9d18dcf3f50c6

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 ..