Issues with JOGL under OS X

Hey. Thought I'd post this here because I can't put my mind around this issue. So, I'm in the midst of reconstructing some extremely old code, and I decided to update JOGL. I'm not even sure what sort of JOGL build the old code was using. Anyway, I successfully updated the libs to a more recent build. The code works with every Windows build I've come across, but for some reason it won't function under OS X. Here's a log with debug-all:

http://pastebin.com/raw.php?i=jsa3cAtG

After that, it's just "NSOpenGLLayer.Attach: Re-Queue, drawableHandle 0x7f7fbb02f9a0 - AWT-AppKit" for an additional 3 billion lines, after which I dispose of everything and return to the original screen. I'm extremely new to OpenGL and JOGL, but I assume there's some sort of information hidden in that log. I will provide code from the project when necessary.

Thanks in advance!

Hi

Please stop using the obsolete Apple JVM. I can find a clear statement of Apple itself about the fact it's deprecated. Run your application with OpenJDK or Oracle Java and it will work.

Hey, thanks for replying. Running Oracle's product now and the output is similar; it didn't work. I haven't tried OpenJDK yet.

http://pastebin.com/raw.php?i=nPjtDfdx

Do you reproduce your bug when not using any applet?

I can't see why it wouldn't, unless the JOGL-related code in the Applet class has something to do with the issue.

I have:

GLCapabilities capabilities = new GLCapabilities(GLProfile.getDefault());
capabilities.setSampleBuffers(true);
capabilities.setNumSamples(2);
Global.mainGLCanvas = new MainGLCanvas(this, capabilities);
((Container)var2).add(Global.mainGLCanvas);

in the applet class, but that's it. MainGLCanvas is a GLCanvas (duh), calls super() with the given capabilities.

This is called on startup.

Yes but you leave out a lot of information. What does "Not work" mean? Surface is all black, Surface is not visible at all, computer transforms into a multidimensional monster that needs to be killed by fire?
Also, in the traces there is for example:

org.stalk.b2.TextureRenderer.method1853(TextureRenderer.java:637)

So try to make a very small self contained example showing the problem, it's the best way to get help.

Surface is black for the time being until it return to the previous screen (though a multidimensional monster is not unheard of...).
It's very hard for me to "make a very small self contained example showing the problem" when I don't know what the problem is. Here's method1853 though: http://pastebin.com/raw.php?i=SxNENQfu

Thank you for the reply.

There is no other solution, we can't fix a bug that we can't reproduce. Your example doesn't show method1840, method1829 and Class3_Sub13_Sub34.method331. Please provide a SSCCE.

agggile wrote

It's very hard for me to "make a very small self contained example showing the problem" when I don't know what the problem is.

I know, but you should take in account that it is even harder for other people finding the error by just looking at one small piece of code.

Of course unless a very rare intuition, but that happens once on 100 times :p

Sorry but there is no other way than going down to a test scenario..

Anyway, I find naming classes/methods like "Class3_Sub13_Sub34.method331" very counter-productive and harmful, you should find a name that reflects its scope

elect wrote

agggile wrote

It's very hard for me to "make a very small self contained example showing the problem" when I don't know what the problem is.

I know, but you should take in account that it is even harder for other people finding the error by just looking at one small piece of code.

Of course unless a very rare intuition, but that happens once on 100 times :p

Sorry but there is no other way than going down to a test scenario..

Anyway, I find naming classes/methods like "Class3_Sub13_Sub34.method331" very counter-productive and harmful, you should find a name that reflects its scope

The code is deobsfucated, no sane person would use naming conventions like that, obviously. It's up to the deobsfucator to come up with the names, and I've only refactored a fraction of what's in there.

Anyway, I assumed the debug would point out the issue as to why it occurs since I can't see why I couldn't deploy identical code on OS X and Windows when the issue doesn't exist on Windows (for whatever reason that is).

gouessej wrote

There is no other solution, we can't fix a bug that we can't reproduce. Your example doesn't show method1840, method1829 and Class3_Sub13_Sub34.method331. Please provide a SSCCE.

Please check the original post. As this is probably not a bug but some sort of misconfiguration from my end instead, I originally assumed that the issue would be clear from the debug. You even thought it was Apple's JVM that caused this, so don't expect for me to know it any better since you're the more advanced user here (I'm honestly clueless ).

but I assume there's some sort of information hidden in that log. I will provide code from the project when necessary.

Nevertheless, the referenced line numbers from TextureRenderer's method1835 are:

var5 = aGLContext1800.makeCurrent();
mainGlObj = aGLContext1800.getGL().getGL2();
GLUgl2.createGLU(aGLContext1800.getGL());

The methods don't make GL calls!

agggile wrote

The code is deobsfucated, no sane person would use naming conventions like that, obviously. It's up to the deobsfucator to come up with the names, and I've only refactored a fraction of what's in there.

Anyway, I assumed the debug would point out the issue as to why it occurs since I can't see why I couldn't deploy identical code on OS X and Windows when the issue doesn't exist on Windows (for whatever reason that is). Thank you all for replying but it looks like I'll have to dive in deep.

Ah sorry, I didn't think about that obfuscation possibility..

Anyway, are you using Nvidia on Windows?

elect wrote

agggile wrote

The code is deobsfucated, no sane person would use naming conventions like that, obviously. It's up to the deobsfucator to come up with the names, and I've only refactored a fraction of what's in there.

Anyway, I assumed the debug would point out the issue as to why it occurs since I can't see why I couldn't deploy identical code on OS X and Windows when the issue doesn't exist on Windows (for whatever reason that is). Thank you all for replying but it looks like I'll have to dive in deep.

Ah sorry, I didn't think about that obfuscation possibility..

Anyway, are you using Nvidia on Windows?

Yeah, running a Quadro FX 880M with the latest drivers!

agggile wrote

Yeah, running a Quadro FX 880M with the latest drivers!

Then you should know a possibility is that the Windows-Nvidia driver is fixing the code for you while the MacOs counterpart is not doing the same.

Nvidia is very well know to not respect properly the OpenGL specifications and allowing some wrong behaviours. This lead devs experience unknown bugs on other platforms or with other HIV gpu

elect wrote

agggile wrote

Yeah, running a Quadro FX 880M with the latest drivers!

Then you should know a possibility is that the Windows-Nvidia driver is fixing the code for you while the MacOs counterpart is not doing the same.

Nvidia is very well know to not respect properly the OpenGL specifications and allowing some wrong behaviours. This lead devs experience unknown bugs on other platforms or with other HIV gpu

Ah, now this is insightful. Thank you for pointing out, do you possibly have a link to any sort of resource that'd provide more light on this?

Actually, I went through the TextureRenderer class and I found something commented out:

int[] var0 = new int[2];
mainGlObj.glGetIntegerv(GL_DRAW_BUFFER, var0, 0);
mainGlObj.glGetIntegerv(GL_READ_BUFFER, var0, 1);
//mainGlObj.glDrawBuffer(GL_BACK_LEFT);
//mainGlObj.glReadBuffer(GL_FRONT_LEFT);

So, I enabled this on OS X and the glDrawBuffer is giving me an INVALID OPERATION error. I might be on to something here.

agggile wrote

Ah, now this is insightful. Thank you for pointing out, do you possibly have a link to any sort of resource that'd provide more light on this?

Unfortunately not, it is something I learnt reading around in the last years, but I read it especially on the opengl forums. You may want to give a try and open a thread over there too

Apple JVM is obsolete:
https://developer.apple.com/library/mac/releasenotes/Java/JavaSnowLeopardUpdate3LeopardUpdate8RN/NewandNoteworthy/NewandNoteworthy.html#//apple_ref/doc/uid/TP40010380-CH4-SW1

agggile wrote

Nevertheless, the referenced line numbers from TextureRenderer's method1835 are:

var5 = aGLContext1800.makeCurrent();
mainGlObj = aGLContext1800.getGL().getGL2();
GLUgl2.createGLU(aGLContext1800.getGL());

The methods don't make GL calls!

GLContext.makeCurrent() makes some OpenGL calls.

I agree with elect concerning Nvidia's drivers but being experts or not changes nothing. If we can't reproduce your problem and if we haven't observed it in the past, we can only make a few guesses but it's still hard to find the culprit.

Moreover, in my humble opinion, almost all OpenGL drivers are to blame under OS X.

agggile, I asked you to provide more information because the crash log tells nothing about your graphics card. I'm not a magician.

gouessej wrote

Apple JVM is obsolete:
https://developer.apple.com/library/mac/releasenotes/Java/JavaSnowLeopardUpdate3LeopardUpdate8RN/NewandNoteworthy/NewandNoteworthy.html#//apple_ref/doc/uid/TP40010380-CH4-SW1

agggile wrote

Nevertheless, the referenced line numbers from TextureRenderer's method1835 are:

var5 = aGLContext1800.makeCurrent();
mainGlObj = aGLContext1800.getGL().getGL2();
GLUgl2.createGLU(aGLContext1800.getGL());

The methods don't make GL calls!

GLContext.makeCurrent() makes some OpenGL calls.

I agree with elect concerning Nvidia's drivers but being experts or not changes nothing. If we can't reproduce your problem and if we haven't observed it in the past, we can only make a few guesses but it's still hard to find the culprit.

Moreover, in my humble opinion, almost all OpenGL drivers are to blame under OS X.

agggile, I asked you to provide more information because the crash log tells nothing about your graphics card. I'm not a magician.

No, I mean the methods you had listed that were being called from method1853. The lines referenced from the logs are those lines that I had just pasted above, but the one method I had pasted earlier had some trivial calls to other methods (which did not make opengl calls unlike method1853)!

I know you're not a magician; and I've never expected you to come up with a magic answer based on what I've given so far, but I'm more than happy to provide you with whatever you see necessary! I had no intention to provoke you with that previous post whatsoever, and I'm sorry if I made it seem so! Yes, Apple JVM turns out to be deprecated, which I hadn't realized. So at least that is sorted now.

There is one last chance ^^

If you have core 4.3 or KHR_debug or ARB_debug_output you can try this.

You can perform it in jogl in the following way

On 10/27/2015 10:49 AM, agggile [via jogamp] wrote:
> Hey. Thought I'd post this here because I can't put my mind around this issue.
> So, I'm in the midst of reconstructing some extremely old code, and I decided
> to update JOGL. I'm not even sure what sort of JOGL build the old code was
> using. Anyway, I successfully updated the libs to a more recent build. The
> code works with every Windows build I've come across, but for some reason it
> won't function under OS X. Here's a log with debug-all:
>
> http://pastebin.com/raw.php?i=jsa3cAtG

Thank you for the log file, I have to analyze it in detail and compare it,
see below.

However, it seems that general initialization has passed and was successful.

+++

It would be great if you could:

- use the latest Oracle JRE for OSX

- try one of our applets on you machine
  and produce the log file.

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

  Also state whether the applets work in general on your machine.

  Best is you can test multiple applets, i.e.
    - one simple one, i.e. Gears
      <http://jogamp.org/deployment/jogamp-current/jogl-applet-runner-newt-gears-normal-napplet.html>

    - one which uses AWT as your applet does,
      look on the bottom of the applet test page
      which include GLCanvas and GLJPanel tests.
      E.g.: <http://jogamp.org/deployment/jogamp-current/jogl-applet-gl2_gljpanel02.html>

- produce the log file w/ the Oracle JRE and your application

- tar+gz/zip the log files and publish them for us.



>
> After that, it's just "NSOpenGLLayer.Attach: Re-Queue, drawableHandle
> 0x7f7fbb02f9a0 - AWT-AppKit" for an additional 3 billion lines, after which I
> dispose of everything and return to the original screen. I'm extremely new to
> OpenGL and JOGL, but I assume there's some sort of information hidden in that
> log. I will provide code from the project when necessary.

It is possible that this issue is somewhat inherent to your application.
Hence we do need all infos as stated above.

~Sven