JOGL crash on system with dual NVIDIA Quadro K600 (dual monitor)

Hi.
I have a VTK-based, JOGL-based application, which works fine with several different hardware configurations we have tested so far, but crashes with a system having the following configuration:

* Intel(R) Xeon(R) CPU E5-2609 v2 @ 2.50GHz   2.50 GHz
* 16 GB RAM
* Two NVIDIA Quadro K600 graphics adapters, each one connected to a 3 MP medical screen
* NVIDIA Driver version 353.62
* A third non-medical display, connected to a "Fresco Logic IDDCX Adapter"
* Windows 10 Pro 64-bit

Basically, my application shows a JFrame on each one of the medical screens connected to the NVIDIA Quadro K600 adapter (let's call them "Screen 1" and "Screen 2"), and each JFrame is created on the GraphicsConfiguration of the related GraphicsDevice.
Eventually, upon invocation of a specific function of my application, a JOGL GLCanvas (showing VTK-generated renderings) is created inside one of these JFrames.

Strangely, my application crashes when the GLCanvas is created inside the JFrame appearing on Screen 1, while it doesn't crash when the GLCanvas is created inside the JFrame appearing on Screen 2 (although both screens should be managed by the same model of graphics card and by the same device driver).

I've tried collecting some debug information. First of all, here is the JOGL debug log (mixed with some minor application logging) when trying to create the GLCanvas inside the JFrame appearing on Screen 1, which results in a CRASH:

REVOutErr_QuadroK600_Screen1_Crash.log

On the other side, here is the JOGL debug log (mixed with some minor application logging) when trying to create the GLCanvas inside the JFrame appearing on Screen 2, which seems to work fine:

REVOutErr_QuadroK600_Screen2_NoCrash.log

Finally, here is the "crash dump" of the JVM when my application crashes, while trying to initialize the GLCanvas on Screen 1:

hs_err_pid89756_QuadroK600_Crash.log

Putting it all together, my application seems to crash within the "jogamp.nativewindow.windows.GDI.SetPixelFormat1()" call:

Java frames: (J=compiled Java code, j=interpreted, Vv=VM code)
j  jogamp.nativewindow.windows.GDI.SetPixelFormat1(JILjava/nio/ByteBuffer;)Z+0
j  jogamp.nativewindow.windows.GDI.SetPixelFormat(JILjogamp/nativewindow/windows/PIXELFORMATDESCRIPTOR;)Z+14
j  jogamp.opengl.windows.wgl.WGLUtil.SetPixelFormat(JILjogamp/nativewindow/windows/PIXELFORMATDESCRIPTOR;)Z+16
j  jogamp.opengl.windows.wgl.WindowsWGLGraphicsConfigurationFactory.updateGraphicsConfiguration(Lcom/jogamp/nativewindow/CapabilitiesChooser;Lcom/jogamp/opengl/GLDrawableFactory;Lcom/jogamp/nativewindow/NativeSurface;[I)V+208
j  jogamp.opengl.windows.wgl.WindowsWGLGraphicsConfiguration.updateGraphicsConfiguration(Lcom/jogamp/opengl/GLDrawableFactory;Lcom/jogamp/nativewindow/NativeSurface;[I)V+7
j  jogamp.opengl.windows.wgl.WindowsWGLDrawable.setRealizedImpl()V+29
j  jogamp.opengl.GLDrawableImpl.setRealized(Z)V+200
j  com.jogamp.opengl.awt.GLCanvas.setRealizedImpl(Z)V+64
j  com.jogamp.opengl.awt.GLCanvas.access$100(Lcom/jogamp/opengl/awt/GLCanvas;Z)V+2
j  com.jogamp.opengl.awt.GLCanvas$3.run()V+5
j  com.jogamp.common.util.awt.AWTEDTExecutor.invoke(Ljava/lang/Object;ZZLjava/lang/Runnable;)Z+8
j  com.jogamp.opengl.awt.GLCanvas.setRealized(Z)V+24
j  com.jogamp.opengl.awt.GLCanvas.validateGLDrawable()Z+60
j  com.jogamp.opengl.awt.GLCanvas.reshapeImpl(II)V+226
j  com.jogamp.opengl.awt.GLCanvas.reshape(IIII)V+21
[...]

Can you guess what can be causing it to crash? What could explain this different behavior between "Screen 1" and "Screen 2" with GLCanvas?

Thanks in advance for any hint you may have.
Best regards,

Marco Sambin

Do you use this release candidate?
https://jogamp.org/deployment/v2.4.0-rc-20210111/

According to the logs, you're using this release candidate.

I've looked at your logs. I see that you use a proprietary docking API, I just hope that it has nothing to do with our problem. It would be better to reproduce your bug on a much smaller and simpler example. I'll see what I can do anyway. I don't understand (yet) why a particular pixel format causes the crash. I'll need your help as I don't have any access to a similar hardware.

Hi Julien,

I will try to run my own JOGL context test cases on that machine, in order to check if a very simply GLCanvas put in a JFrame still causes a JVM crash on the NVIDIA Quadro K600-based PC or not.

Unfortunately, that PC is not under my control, and I need to ask customer's permission each time I need to access to it.
However, I hope to be able to bring useful debug information in my next test with the simpler test cases.

I will get back to you ASAP, maybe tomorrow afternoon.
Thanks and best regards,

Marco Sambin

Hello Marco

I've just finished comparing the logs. I'm a bit sad. Actually, the exact same pixel format is used in both situations, there's no faulty pixel format, there is no room to implement a quirk within JOGL in my humble opinion. The chosen pixel format is suitable for one screen but not for another one. Either you provide a reproducer to Nvidia or you find a solution to work around this problem in JOGL but I'm not sure that it exists. Why not trying to display a triangle on both screens with NEWT without AWT and Swing? You can choose a physical or logical monitor in NEWT, it would probably pick another pixel format.

As a first step, I suggest you to run this rudimentary example on both screens (please start it on the right screen, don't move it from one screen to another one as a first step):
https://jogamp.org/wiki/index.php/Rudimentary_standalone_example_using_the_fixed_pipeline_by_Julien_Gouesse

As a second step, modify the example above to use NEWT, connect only one screen at a time, run the modified example on each screen.

Hi Julien,

thanks a lot for your feedback and for taking the time to complete the analysis of the logs.

On my side, I am still waiting that the customer allows me to re-connect to this workstation powered by these two NVIDIA Quadro K600 adapters: I have a couple of simple JOGL-only tests to run, and to collect logs.

Also, I have a modified version of my (VTK+JOGL)-based application, using vtkJoglPanelComponent instead of vtkJoglCanvasComponent (i.e., GLJPanel instead of GLCanvas): I want to check if this makes a different w.r.t. crashes on this specific hardware configuration.

I will report back as soon as possible.

Thanks again and best regards,

Marco Sambin

Please think about disabling the build-in GLSL shader when using GLJPanel just in case it matters.

Hi all.

Finally, yesterday I had again the opportunity to connect to the workstation with two NVIDIA Quadro K600 adapter (each one connected to a dedicated medical display), and perform more tests.

I have used these two modified versions of my JOGL-only test cases:

JoglContextTestCase.java (using GLCanvas)

JoglJPanelContextTestCase.java (using GLJPanel)

Here are the results:

1) When I run JoglContextTestCase with command line parameter "0" (asking to open the JFrame containing GLCanvas on Device # 0 - i.e., the first medical display), I obtain a crash. Here is the log for this test:

JOGLTestLog_Device0.txt

2) When I run JoglContextTestCase with command line parameter "1" (asking to open the JFrame containing GLCanvas on Device # 1 - i.e., the second medical display), everything seems to work fine. Here is the log for this test:

JOGLTestLog_Device1.txt

3) When I run JoglJPanelContextTestCase with command line parameter "0" (asking to open the JFrame containing GLJPanel on Device # 0 - i.e., the first medical display), everything works fine. Here is the log for this test:

JOGLJPanelTestLog_Device0.txt

4) When I run JoglJPanelContextTestCase with command line parameter "1" (asking to open the JFrame containing GLJPanel on Device # 1 - i.e., the second medical display), everything works fine. Here is the log for this test:

JOGLJPanelTestLog_Device1.txt

So, in summary, using GLJPanel seems to work fine on this workstation, while using GLCanvas seems to work fine only on the second screen, while on the first screen (always connected to the same identical kind of graphics adapter - NVIDIA Quadro K600) it causes a JVM crash.

This exactly reflects the behavior of my VTK-based + JOGL-based application: I managed to set it to force VTK to use GLJPanel instead of GLCanvas, and in this mode it works fine (although with a performance penalty) and doesn't crash on this workstation. On the other side, when I set my application to force VTK to use GLCanvas, my application crashes on the first medical monitor, but works fine on the second medical monitor.

Let me know if all these logs are able to provide additional information and help in diagnosing eventual issues.

Thanks and best regards,

Marco Sambin

Sorry for the late reply. I'm carefully reading the logs right now.

There is something wrong in your source code, there is no need to call GLContext.makeCurrent() in GLEventListener.init() because this method is called immediately after the OpenGL context is initialized, it's intended to be current so that you can perform your one-time OpenGL initialization.

skipCapsChooser is set to true when it works on both screens. I have to investigate. Thank you very much for the logs.

Please can you use a LTS version of Java to perform your test instead of Java 1.8.0u252 (preferably Java 17 or in the worst case Java 11)?

Hello Marco

Please can you rerun your tests with -Dsun.java2d.opengl=false -Dsun.java2d.noddraw=true and OpenJDK 11 or preferably 17 (see Adoptium)?

Please can you try to override DefaultGLCapabilitiesChooser so that it picks available.get(windowSystemRecommendedChoice) systematically when windowSystemRecommendedChoice is a valid index (i.e not negative)? It's a first try, I'll provide something better if it works.

Hi Julien,

I will try to run the suggested tests as soon as possible.

However, since this is a customer machine installed in a diagnostic center, it isn't easy to find a time window where the workstation isn't in use by the radiologists. That's why last time I tried to perform all tests that came to my mind, and to provide the most complete logs I could think of.

The "-Dsun.java2d.noddraw=true" was already set in all my tests, and it is the default for my application. The "-Dsun.java2d.opengl=false" system property was NOT explicitly set, but I think "false" is the default setting for this property, so I don't expect changes by explicitly passing this command line parameter. I will try, though.

Using a different OpenJDK version to run my tests will be a bit more complex, as for my tests I am using the JRE embedded with my application, which is still a Java 8 indeed. Testing with a newer JRE will imply installing a new JRE on the customer's machine: I will ask permission to do that.

I will try and get back to you ASAP.

In the meanwhile, thanks a lot for your analysis, I really appreciate your efforts.

Best regards,

Marco Sambin

Hello Marco

If the Java2D OpenGL pipeline is turned off, it will eliminate a source of side effects for sure. This pipeline isn't on by default, it depends on the platform, the bitness, etc. The two flags are mentioned in the documentation of the GLCanvas class as far as I remember. The only way to be sure that it's off consists in turning it off.

I could prepare a demo with a bundled JRE by using JNDT but I'm not sure that your customer would allow you to run it on her/his hardware :s You can unzip OpenJDK without "installing" on the system anyway, use the ZIP archive instead of the MSI package.

I really think that there is a badly managed very specific corner case in the chooser.