Bug 1183

I recall i have seen this exception and remember it to be caused because the static initialization of
GraphicsConfigurationFactory.initSingleton();
has not yet been run.

In most JOGL applications
GraphicsConfigurationFactory.initSingleton();
is triggered during the NativeWindowFactory static block
before you create a NewtWindow.

Processing 3 codebase initializes the NEWT Screen early before reaching the line when it create the Newt Window.
https://github.com/processing/processing/blob/master/core/src/processing/opengl/PSurfaceJOGL.java#L100-L123

I will try reproduce the bug and check if i can remedy it by placing a
GraphicsConfigurationFactory.initSingleton();
inside the X11 ScreenDriver static block since the ScreenDriver depend on that GraphicsConfigurationFactory has been initialized.

If you are running on a raspberry pi system with both the /opt/vc driver and the /usr/lib/... mesa3d driver present then
GraphicsConfigurationFactory.initSingleton()
will skip to register X11 because it think it is on a bcm.vc.iv system.

http://jogamp.org/git/?p=jogl.git;a=blob;f=src/nativewindow/classes/com/jogamp/nativewindow/GraphicsConfigurationFactory.java;hb=HEAD#l121

A workaround to allow your program to create both X11 and bcm.vc.iv newt window at the same time is to run the following code early in your program.

GraphicsConfigurationFactory.initSingleton()
try {
    ReflectionUtil.callStaticMethod("jogamp.nativewindow.x11.X11GraphicsConfigurationFactory",
                                    "registerFactory", null, null, GraphicsConfigurationFactory.class.getClassLoader());
} catch (final Exception e) {
    throw new RuntimeException(e);
}

I can reproduce this bug using the
20150726-1747-vc4-image.zip system image from
http://sukzessiv.net/~gohai/vc4-buildbot/build/
when running the YellowTail processing 3 demo
with the X11 mesa3d driver installed and
without the /opt/vc driver.

It do not trigger all the time. If I re-run the demo then it launches fine.

The thesis in comment #2 that both the /opt/vc and /usr/lib mesa3d has to be installed at the same time to trigger this bug is not true.

We need to ensure the static initialization order as suggested in comment #1 and as discussed in jogamp irc:
http://jogamp.org/log/irc/jogamp_20150727135426.html#l74

This seems to happens less frequently for me on http://sukzessiv.net/~gohai/vc4-buildbot/build/20150727-1947-vc4-image.zip, which has a recent snapshot of JOGL, but it still happens.

The Processing demo that made it trigger two out of three tries for me with this build was: Demos/Tests/SpecsTest.

Thanks for looking into this!

"Xerxes' fixes on top", referring to Xerxes WIP regarding Bug 1178.

Sorry for not being specific enough.. I was referring to the JavaEmitter's JVMUtil_NewDirectByteBufferCopy one. Also seeing this with autobuild from July 25.

This crash is confined to the Raspi ARM?
This crash is confined to Eric's 'alpha' OpenGL driver?

(In reply to comment #7)
> This crash is confined to the Raspi ARM?
> This crash is confined to Eric's 'alpha' OpenGL driver?

If I digg through these issues, I need to know a reliable recipe 
for reproduction ofc ..

It would be nice, if this can be reproduced w/ our unit tests
or a new unit test! Same for Bug 1185.

Created attachment 715 [details]
TestInitScreen.java

The attached test-program TestInitScreen.java can reproduce this bug in about  one of three runs using a
RaspberryPi 1 b+ (the "old" one using an armv6 cpu)

Steps to reproduce:
Boot the pi to X11, I was using Eric Anholts experimental X11 glamor driver when I managed to reproduce this.

javac -cp jogamp-fat.jar:. TestInitScreen.java
java -cp jogamp-fat.jar:. TestInitScreen

Output:
pi@raspberrypi ~/2.3.2 $ java -cp jogamp-fat.jar:. TestInitScreen 
Exception in thread "main" java.lang.NullPointerException
	at jogamp.newt.driver.x11.ScreenDriver.collectNativeMonitorModesAndDevicesImpl(ScreenDriver.java:124)
	at jogamp.newt.ScreenImpl.collectNativeMonitorModes(ScreenImpl.java:630)
	at jogamp.newt.ScreenImpl.initMonitorState(ScreenImpl.java:566)
	at jogamp.newt.ScreenImpl.createNative(ScreenImpl.java:196)
	at jogamp.newt.ScreenImpl.addReference(ScreenImpl.java:235)
	at TestInitScreen.testInitScreenBug1183(TestInitScreen.java:42)
	at TestInitScreen.main(TestInitScreen.java:46)
X11Util.Display: Shutdown (JVM shutdown: true, open (no close attempt): 1/1, reusable (open, marked uncloseable): 0, pending (open in creation order): 1)
X11Util: Open X11 Display Connections: 1
X11Util: Open[0]: NamedX11Display[:0.0, 0xb61d20, refCount 1, unCloseable false]

(In reply to comment #7)
> This crash is confined to the Raspi ARM?
> This crash is confined to Eric's 'alpha' OpenGL driver?

It can be reproduced with both the "regular" framebuffer X11 driver found on the default Raspbian system
and
by using Eric Anholt's glamour X11 driver.


It is *very* easy to reproduce this bug using the "regular" X11 framebuffer driver + mesa3d software rasterizer using a Raspbian system if you disable the bcm.vc.iv driver by moving the
/opt/vc to /opt/vc.off

and then run the test program:

javac -cp jogamp-fat.jar:. TestInitScreen.java
java -cp jogamp-fat.jar:. TestInitScreen

(In reply to comment #10)
> (In reply to comment #7)
> > This crash is confined to the Raspi ARM?
> > This crash is confined to Eric's 'alpha' OpenGL driver?
> 
> It can be reproduced with both the "regular" framebuffer X11 driver found on
> the default Raspbian system
> and
> by using Eric Anholt's glamour X11 driver.
> 
> 
> It is *very* easy to reproduce this bug using the "regular" X11 framebuffer
> driver + mesa3d software rasterizer using a Raspbian system if you disable
> the bcm.vc.iv driver by moving the
> /opt/vc to /opt/vc.off
> 
> and then run the test program:
> 
> javac -cp jogamp-fat.jar:. TestInitScreen.java
> java -cp jogamp-fat.jar:. TestInitScreen

Its easy to reproduce this on a raspberry pi 2 (quad core armv7) as well as using the raspberry pi 1 (singlecore armv6) when using the X11 framebuffer driver + mesa3d software rasterizer.
Its near 100% reproduction rate when you move the opt/vc to /opt/vc.off

jogl 4ff4f735c421ef343a8c447fa699c01444bd5e9b
    Bug 1183: Handle NULL return values for native RandR13 calls, 
    which suppose to return 'int[]'
    
    Certain native RandR13 functions shall return 'int[]',
    but will bail out early in case of an error or lack of resources.
    
    The latter is true for getMonitorDeviceIds(..)
    where 'XRRScreenResources->ncrtc <= 0', causing return value NULL.
    
    This patch handles the NULL return values,
    however, the root cause of having 'XRRScreenResources->ncrtc <= 0'
    _occasionally_ lies within the Raspi X11 driver I am afraid?!

(In reply to comment #12)
> jogl 4ff4f735c421ef343a8c447fa699c01444bd5e9b
>     Bug 1183: Handle NULL return values for native RandR13 calls, 
>     which suppose to return 'int[]'
>     
>     Certain native RandR13 functions shall return 'int[]',
>     but will bail out early in case of an error or lack of resources.
>     
>     The latter is true for getMonitorDeviceIds(..)
>     where 'XRRScreenResources->ncrtc <= 0', causing return value NULL.
>     
>     This patch handles the NULL return values,
>     however, the root cause of having 'XRRScreenResources->ncrtc <= 0'
>     _occasionally_ lies within the Raspi X11 driver I am afraid?!

It should fall back to a fake entry using the virtual size within NEWT.

If you can confirm this .. please set this bug to validated, thx!

I can confirm that I no longer can see the exception when
jogl 4ff4f735c421ef343a8c447fa699c01444bd5e9b
is applied.

(In reply to comment #12)
> jogl 4ff4f735c421ef343a8c447fa699c01444bd5e9b
>     Bug 1183: Handle NULL return values for native RandR13 calls, 
>     which suppose to return 'int[]'
>     
>     Certain native RandR13 functions shall return 'int[]',
>     but will bail out early in case of an error or lack of resources.
>     
>     The latter is true for getMonitorDeviceIds(..)
>     where 'XRRScreenResources->ncrtc <= 0', causing return value NULL.
>     
>     This patch handles the NULL return values,
>     however, the root cause of having 'XRRScreenResources->ncrtc <= 0'
>     _occasionally_ lies within the Raspi X11 driver I am afraid?!

I found this upstream xorg bug, that includes a possible workaround!
It is a possibility that this bug only trigger when using RandR in combination with an xorg driver that are not yet fully randr1.2 compatible.

https://bugs.freedesktop.org/show_bug.cgi?id=20270 - 
XRRGetScreenResourcesCurrent (or XRRGetScreenResources) reports empty data until XRRGetScreenSizeRange is called on non randr1.2 drivers

Created attachment 716 [details]
commit-15a7e36-cleanup-javadoc-signature-comments.patch

Spotted some javadoc and comment typos while reading RandR code related to this bug.
Feel free to merge using the patch attached.

Bug 1183: Cleanup x11/RandR javadoc and native/X11RandR13 signature comments.

Thanks Sven & Xerxes!

I am still a bit confused why this only hits occasionally and not for every invocation.. might be totally unrelated, but Processing just merged a fix related to screen device parsing (https://github.com/gohai/processing/commit/844501686ce509c21b9856d1accae7f41e729060) - testing in a bit with the JOGL fix and this on top.

I was testing with the new Mesa driver today, and instead of the NullPointerException I am now seeing the error below. Is this indeed the same root cause - outside of JOGL's codebase - not manifesting itself like this? Thanks!

FATAL ERROR in native method: Nativewindow X11 IOError: Display 0x3dc5ee0 (:0): Resource temporarily unavailable
Nativewindow X11 IOError: Display 0x3dc5ee0 (:0): Resource temporarily unavailable
Nativewindow X11 IOError: Display 0x3dc5ee0 (:0): Resource temporarily unavailable
	at jogamp.newt.driver.x11.WindowDriver.CreateWindow0(Native Method)
	at jogamp.newt.driver.x11.WindowDriver.CreateWindow(WindowDriver.java:445)
	at jogamp.newt.driver.x11.WindowDriver.createNativeImpl(WindowDriver.java:130)
	at jogamp.newt.WindowImpl.createNative(WindowImpl.java:460)
	at jogamp.newt.WindowImpl.setVisibleActionImpl(WindowImpl.java:975)
	at jogamp.newt.WindowImpl$VisibleAction.run(WindowImpl.java:1026)
	at com.jogamp.common.util.RunnableTask.run(RunnableTask.java:150)
	- locked <0x65a60628> (a java.lang.Object)
	at jogamp.newt.DefaultEDTUtil$NEDT.run(DefaultEDTUtil.java:372)

(In reply to comment #18)
> I was testing with the new Mesa driver today, and instead of the
> NullPointerException I am now seeing the error below. Is this indeed the
> same root cause - outside of JOGL's codebase - not manifesting itself like
> this? Thanks!
> 
> FATAL ERROR in native method: Nativewindow X11 IOError: Display 0x3dc5ee0
> (:0): Resource temporarily unavailable
> Nativewindow X11 IOError: Display 0x3dc5ee0 (:0): Resource temporarily
> unavailable
> 	at jogamp.newt.driver.x11.WindowDriver.CreateWindow0(Native Method)
...
> 	at jogamp.newt.DefaultEDTUtil$NEDT.run(DefaultEDTUtil.java:372)

This is a different issue
i have filed a new bug 1187
https://jogamp.org/bugzilla/show_bug.cgi?id=1187
to track it.

jogl 217d8b78a3d70d9be59d4537c7565118dfe1e277
    Bug 1183: Cleanup x11/RandR javadoc and native/X11RandR13 signature comments

(In reply to comment #15)
> (In reply to comment #12)
> > jogl 4ff4f735c421ef343a8c447fa699c01444bd5e9b
> >     Bug 1183: Handle NULL return values for native RandR13 calls, 
> >     which suppose to return 'int[]'
> >     
> >     Certain native RandR13 functions shall return 'int[]',
> >     but will bail out early in case of an error or lack of resources.
> >     
> >     The latter is true for getMonitorDeviceIds(..)
> >     where 'XRRScreenResources->ncrtc <= 0', causing return value NULL.
> >     
> >     This patch handles the NULL return values,
> >     however, the root cause of having 'XRRScreenResources->ncrtc <= 0'
> >     _occasionally_ lies within the Raspi X11 driver I am afraid?!
> 
> I found this upstream xorg bug, that includes a possible workaround!
> It is a possibility that this bug only trigger when using RandR in
> combination with an xorg driver that are not yet fully randr1.2 compatible.
> 
> https://bugs.freedesktop.org/show_bug.cgi?id=20270 - 
> XRRGetScreenResourcesCurrent (or XRRGetScreenResources) reports empty data
> until XRRGetScreenSizeRange is called on non randr1.2 drivers

I have seen this bug trigger on a x86_64 system as well using the jogl 2.3.1
an a laptop using a intel i916 + X.Org X Server 1.15.1

thus the root cause of having 'XRRScreenResources->ncrtc <= 0'
_occasionally_ lies generally within all xorg drivers

this bug has made bugreport rounds in all linux distributions yet no-one have fixed xorg instead they added workarounds to all applications using xrandr such as gtk, gdm...

example
Frederic Crozat proposed one workaround fix for this bug to gtk
https://bugzilla.gnome.org/show_bug.cgi?id=572387#c2
https://bugzilla.gnome.org/attachment.cgi?id=129071&action=diff

the reason the xrandr tool always work seems to be that it always uses XRRGetScreenSizeRange before calling XRRGetScreenResourcesCurrent or XRRGetScreenResources

we want to add this workaround.
by having XRRScreenResources->ncrtc allways containing valid data would make jogl better.

(In reply to comment #21)

Branch ready to merge: https://github.com/xranby/jogl/tree/Bug1183
https://github.com/xranby/jogl/commit/a213c39fa9d741d519df56bc4d4abb86113985f4

    Bug 1183
    XRRGetScreenResourcesCurrent (or XRRGetScreenResources)
    _occasionally_ reports empty data
    unless XRRGetScreenSizeRange has been called once.

commit a213c39fa9d741d519df56bc4d4abb86113985f4

XRRGetScreenResourcesCurrent (or XRRGetScreenResources)
_occasionally_ reports empty data
unless XRRGetScreenSizeRange has been called once.
Hence call XRRGetScreenSizeRange first!