Bug 1201 - Crash with option "sun.java2d.d3d=false"
Summary: Crash with option "sun.java2d.d3d=false"
Status: CONFIRMED
Alias: None
Product: Java3D
Classification: Unclassified
Component: core (show other bugs)
Version: unspecified
Hardware: All windows
: --- major
Assignee: Phil Jordan
URL: http://forum.jogamp.org/Java-3D-crash...
Depends on:
Blocks:
 
Reported: 2015-08-27 11:01 CEST by Adrien
Modified: 2016-11-01 06:38 CET (History)
2 users (show)

See Also:
Type: DEFECT
SCM Refs:
Workaround: ---


Attachments
log with "sun.java2d.d3d=false" (475.06 KB, text/plain)
2015-08-27 11:01 CEST, Adrien
Details
log with "sun.java2d.d3d=true" (478.53 KB, text/plain)
2015-08-27 11:02 CEST, Adrien
Details
log with "sun.java2d.d3d=false" and "sun.java2d.noddraw=true" (504.72 KB, text/plain)
2015-08-27 11:03 CEST, Adrien
Details
results of test.manual.run (1.17 KB, application/x-7z-compressed)
2015-08-27 13:59 CEST, Adrien
Details
results of test.manual.run in win32 (286 bytes, application/x-7z-compressed)
2015-08-28 12:38 CEST, Adrien
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Adrien 2015-08-27 11:01:20 CEST
Created attachment 725 [details]
log with "sun.java2d.d3d=false"

Here is my test code:
SimpleUniverse universe = new SimpleUniverse();

I got some flickering so I added the following option:
System.setProperty("sun.java2d.d3d", "false");

It works fine with Java 1.6, but with Java 1.7 and higher it crashes with the following message:

com.jogamp.opengl.GLException: J3D-Renderer-1: createImpl ctx !ARB but ARB is used, profile > GL2 requested (OpenGL >= 3.1). Requested: GLProfile[GL4bc/GL4bc.hw], current: 1.1 (Compat profile, compat[], hardware) - 1.1.0
	at jogamp.opengl.windows.wgl.WindowsWGLContext.createImpl(WindowsWGLContext.java:377)
	at jogamp.opengl.GLContextImpl.makeCurrentWithinLock(GLContextImpl.java:759)
	at jogamp.opengl.GLContextImpl.makeCurrent(GLContextImpl.java:642)
	at jogamp.opengl.GLContextImpl.makeCurrent(GLContextImpl.java:580)
	at javax.media.j3d.JoglPipeline.createNewContext(JoglPipeline.java:6412)
	at javax.media.j3d.Canvas3D.createNewContext(Canvas3D.java:4602)
	at javax.media.j3d.Canvas3D.createNewContext(Canvas3D.java:2376)
	at javax.media.j3d.Renderer.doWork(Renderer.java:881)
	at javax.media.j3d.J3dThread.run(J3dThread.java:271)

DefaultRenderingErrorListener.errorOccurred:
CONTEXT_CREATION_ERROR: Renderer: Error creating Canvas3D graphics context
graphicsDevice = Win32GraphicsDevice[screen=0]
canvas = javax.media.j3d.Canvas3D[canvas0,0,0,240x217]

In my application, weirdly, it doesn't crash straight away but when opening the 3D view for the second time.

I've attached the logs with the options -Dnewt.debug=all -Dnativewindow.debug=all -Djogl.debug=all with "sun.java2d.d3d=false" and "sun.java2d.d3d=true".
Comment 1 Adrien 2015-08-27 11:02:07 CEST
Created attachment 726 [details]
log with "sun.java2d.d3d=true"
Comment 2 Adrien 2015-08-27 11:03:32 CEST
Created attachment 727 [details]
log with "sun.java2d.d3d=false" and "sun.java2d.noddraw=true"
Comment 3 Julien Gouesse 2015-08-27 13:16:00 CEST
The rudimentary example I put into the wiki doesn't help to reproduce this bug. Please run the unit tests in JOGL (Ant targets "test.manual.run" and "test.auto.run", I did the same for the bug 1078, I need to reproduce it with JOGL and it would help to understand why it happens only the second time that you create a 3D window.

This patch will be helpful for the renderer quirk:
http://forum.jogamp.org/Java-3D-crash-or-flickering-tp4035074p4035085.html

Skipping the ARB contexts is a very bad idea as there's no non ARB context available.
Comment 4 Adrien 2015-08-27 13:59:17 CEST
Created attachment 728 [details]
results of test.manual.run
Comment 5 Adrien 2015-08-27 14:04:08 CEST
I've attached the results of "test.manual.run". The window that appears at the beginning in empty.
I tried to run "test.auto.run", but I get a series of exceptions saying:
java.lang.UnsatisfiedLinkError: (...)\natives\windows-amd64\gluegen-rt.dll: Can't load IA 32-bit .dll on a AMD 64-bit platform
Comment 6 Julien Gouesse 2015-08-27 17:15:30 CEST
You can use a 32-bit JVM just to run those tests, it should work even though those errors are annoying.
Comment 7 Adrien 2015-08-28 12:38:02 CEST
Created attachment 729 [details]
results of test.manual.run in win32
Comment 9 Julien Gouesse 2015-08-31 10:58:17 CEST
(In reply to comment #8)
> Results of the auto run:
> https://www.dropbox.com/s/o88pekq3ue1gwlu/jogl-2.3-bmanual-20150828-windows-
> i586-test-results-local.7z?dl=0

I see no failed test, am I wrong?
Comment 10 Adrien 2015-09-01 10:15:24 CEST
(In reply to comment #9)
> (In reply to comment #8)
> > Results of the auto run:
> > https://www.dropbox.com/s/o88pekq3ue1gwlu/jogl-2.3-bmanual-20150828-windows-
> > i586-test-results-local.7z?dl=0
> 
> I see no failed test, am I wrong?

Definitely no failed test for the manual run.
For the auto run, I had to stop the JVM several times as the process was blocked. But apart from that, everything seemed ok.
Comment 11 Phil Jordan 2016-11-01 00:06:22 CET
Here is the simplest test case

Note that the JFrame win line moved before getPreferredConfiguration result in no failure, and without System.setProperty("sun.java2d.noddraw", "true"); nothing fails.

You can also make this fail, by moving the JFrame constructor up and simply calling go twice. 

public static void main(final String[] args)
	{
		System.setProperty("sun.java2d.noddraw", "true");
		go();
	}
public static void go()
{
		
		GraphicsConfiguration config2 = SimpleUniverse.getPreferredConfiguration();
		
		JFrame win = new JFrame("ImageJ 3D Viewer");
		// this constructor before the getPreferredConfiguration call results in no fail
		
		Canvas3D c1 = new Canvas3D(config2);
		SimpleUniverse univ1 = new SimpleUniverse(c1);
		univ1.getViewingPlatform().setNominalViewingTransform();

		BranchGroup scene1 = createSceneGraph();
		univ1.addBranchGraph(scene1);

		JPanel drawingPanel = new JPanel();
		drawingPanel.setLayout(new BorderLayout());
		drawingPanel.setPreferredSize(new Dimension(250, 250));
		drawingPanel.add(univ1.getCanvas(), java.awt.BorderLayout.CENTER);

		win.getContentPane().add(drawingPanel, java.awt.BorderLayout.CENTER);
		win.pack();
		win.setVisible(true);		
	
	}
	

	public static BranchGroup createSceneGraph() {
		BranchGroup objRoot = new BranchGroup();
		TransformGroup objTrans = new TransformGroup();
		objTrans.setCapability(TransformGroup.ALLOW_TRANSFORM_WRITE);
		objRoot.addChild(objTrans);
		objTrans.addChild(new ColorCube(0.4));
		Transform3D yAxis = new Transform3D();
		Alpha rotationAlpha = new Alpha(-1, 4000);

		RotationInterpolator rotator = new RotationInterpolator(rotationAlpha, objTrans, yAxis, 0.0f,
				(float) Math.PI * 2.0f);
		BoundingSphere bounds = new BoundingSphere(new Point3d(0.0, 0.0, 0.0), 100.0);
		rotator.setSchedulingBounds(bounds);
		objRoot.addChild(rotator);
		objRoot.compile();
		return objRoot;
	}
Comment 12 Phil Jordan 2016-11-01 01:11:23 CET
Ok in the class
Win32GraphicsDevice
I see this 

   static {

        // 4455041 - Even when ddraw is disabled, ddraw.dll is loaded when
        // pixel format calls are made.  This causes problems when a Java app
        // is run as an NT service.  To prevent the loading of ddraw.dll
        // completely, sun.awt.nopixfmt should be set as well.  Apps which use
        // OpenGL w/ Java probably don't want to set this.
        String nopixfmt = (String)java.security.AccessController.doPrivileged(
            new sun.security.action.GetPropertyAction("sun.awt.nopixfmt"));
        pfDisabled = (nopixfmt != null);
        initIDs();
    }

so when I add this:
System.setProperty("sun.awt.nopixfmt", "true");
after this
System.setProperty("sun.java2d.noddraw", "true");
in my test case, I no longer get any issues.
However I don't know what effect pfDisabled=true will cause elsewhere

As noted before this only discernible different with the noddraw property true is
Outputs this (false):
getDevice D3DGraphicsDevice[screen=0]
getDevice class name sun.java2d.d3d.D3DGraphicsDevice
instead of this (true):
getDevice Win32GraphicsDevice[screen=0]
getDevice class name sun.awt.Win32GraphicsDevice

and with 

System.setProperty("sun.awt.nopixfmt", "true");

The device is still Win32GraphicsDevice
Comment 14 Phil Jordan 2016-11-01 06:38:39 CET
This bug is now explained in the JoglPipeline, when detected
see
Bug 1333 - Warning notice in cases where Jogl bug 1278 is in effect

So it looks like there will not be a solution only the workaround