[SOLVED] Jme3.5.0-alpha on armhf

Today i tried jme3.5.0-alpha on raspberry and i got this exception :

pi@raspberrypi:~/NativeJmeTemplate/output/run $ ./run.sh 
Run
..................................
Dec 09, 2021 12:44:14 PM com.jme3.system.JmeDesktopSystem initialize
INFO: Running on jMonkeyEngine 3.5.0-alpha1
 * Branch: HEAD
 * Git Hash: dc91668
 * Build Date: 2021-11-14
Dec 09, 2021 12:44:16 PM com.jme3.system.lwjgl.LwjglContext printContextInitInfo
INFO: LWJGL 3.3.0 build 21 context running on thread jME3 Main
 * Graphics Adapter: GLFW 3.4.0 Wayland X11 GLX Null EGL OSMesa monotonic shared
Dec 09, 2021 12:44:16 PM com.jme3.renderer.opengl.GLRenderer loadCapabilitiesCommon
INFO: OpenGL Renderer Information
 * Vendor: Broadcom
 * Renderer: V3D 4.2
 * OpenGL Version: 2.1 Mesa 19.3.2
 * GLSL Version: 1.20
 * Profile: Compatibility
Dec 09, 2021 12:44:16 PM com.jme3.asset.AssetConfig loadText
WARNING: Cannot find loader com.jme3.scene.plugins.ogre.MeshLoader
Dec 09, 2021 12:44:16 PM com.jme3.asset.AssetConfig loadText
WARNING: Cannot find loader com.jme3.scene.plugins.ogre.SkeletonLoader
Dec 09, 2021 12:44:16 PM com.jme3.asset.AssetConfig loadText
WARNING: Cannot find loader com.jme3.scene.plugins.ogre.MaterialLoader
Dec 09, 2021 12:44:16 PM com.jme3.asset.AssetConfig loadText
WARNING: Cannot find loader com.jme3.scene.plugins.ogre.SceneLoader
Dec 09, 2021 12:44:16 PM com.jme3.asset.AssetConfig loadText
WARNING: Cannot find loader com.jme3.scene.plugins.fbx.FbxLoader
Dec 09, 2021 12:44:16 PM com.jme3.asset.AssetConfig loadText
WARNING: Cannot find loader com.jme3.scene.plugins.gltf.GltfLoader
Dec 09, 2021 12:44:16 PM com.jme3.asset.AssetConfig loadText
WARNING: Cannot find loader com.jme3.scene.plugins.gltf.BinLoader
Dec 09, 2021 12:44:16 PM com.jme3.asset.AssetConfig loadText
WARNING: Cannot find loader com.jme3.scene.plugins.gltf.GlbLoader
Dec 09, 2021 12:44:16 PM com.jme3.asset.AssetConfig loadText
WARNING: Cannot find loader com.jme3.audio.plugins.OGGLoader
Dec 09, 2021 12:44:16 PM com.jme3.app.LegacyApplication handleError
SEVERE: Uncaught exception thrown in Thread[jME3 Main,5,main]
java.lang.NullPointerException
	at org.lwjgl.system.Callback.get(Callback.java:190)
	at org.lwjgl.glfw.GLFWWindowSizeCallback.create(GLFWWindowSizeCallback.java:36)
	at org.lwjgl.glfw.GLFWWindowSizeCallback.createSafe(GLFWWindowSizeCallback.java:45)
	at org.lwjgl.glfw.GLFW.glfwSetWindowSizeCallback(GLFW.java:3139)
	at com.jme3.input.lwjgl.GlfwMouseInput.initCallbacks(GlfwMouseInput.java:243)
	at com.jme3.input.lwjgl.GlfwMouseInput.initialize(GlfwMouseInput.java:184)
	at com.jme3.app.LegacyApplication.initInput(LegacyApplication.java:337)
	at com.jme3.app.LegacyApplication.initialize(LegacyApplication.java:640)
	at com.jme3.app.SimpleApplication.initialize(SimpleApplication.java:198)
	at com.jme3.system.lwjgl.LwjglWindow.initInThread(LwjglWindow.java:524)
	at com.jme3.system.lwjgl.LwjglWindow.run(LwjglWindow.java:640)
	at com.jme3.system.lwjgl.LwjglWindow.create(LwjglWindow.java:477)
	at com.jme3.app.LegacyApplication.start(LegacyApplication.java:491)
	at com.jme3.app.LegacyApplication.start(LegacyApplication.java:443)
	at com.jme3.app.SimpleApplication.start(SimpleApplication.java:126)
	at test.TestJni.main(TestJni.java:18)

Dec 09, 2021 12:44:16 PM com.jme3.app.LegacyApplication handleError
SEVERE: Failed to destroy context
java.lang.NullPointerException
	at org.lwjgl.system.Callback.get(Callback.java:190)
	at org.lwjgl.glfw.GLFWErrorCallback.create(GLFWErrorCallback.java:40)
	at org.lwjgl.glfw.GLFWErrorCallback.createSafe(GLFWErrorCallback.java:49)
	at org.lwjgl.glfw.GLFW.glfwSetErrorCallback(GLFW.java:1288)
	at com.jme3.system.lwjgl.LwjglWindow.destroyContext(LwjglWindow.java:436)
	at com.jme3.system.lwjgl.LwjglWindow.deinitInThread(LwjglWindow.java:624)
	at com.jme3.system.lwjgl.LwjglWindow.lambda$initInThread$12(LwjglWindow.java:494)
	at java.base/java.lang.Thread.dispatchUncaughtException(Thread.java:2002)

X Error of failed request:  BadWindow (invalid Window parameter)
  Major opcode of failed request:  20 (X_GetProperty)
  Resource id in failed request:  0x1a00061
  Serial number of failed request:  1818
  Current serial number in output stream:  1818

I am currently using Ant on the rpi, dependencies :

those are the dependencies in case i am missing something !

I still haven’t investigated into this problem, but seems to be an incompatibility behavior or lwjgl3.3.0 is the problem !

The same app works fine on my laptop.

1 Like

Alright, i tested w/ lwjgl3.2.3 and it works on both jme3.4 and jme3.5 dependencies, the problem is with lwjgl3.3.0 may be they still didn’t support armhf.

EDIT : Should we downgrade lwjgl3.3.0 to lwjgl3.2.3 ? At least for arm32 devices, so create a new variable for arm and use it for arm32 systems ?

Looks like a potential bug in GLFW. Or we are just using it wrong…

1 Like

Is it a problem with the build of JME or with the application’s dependencies? Because if it’s just the latter then JME doesn’t necessarily need to do anything as users are free to override the lwjgl version locally.

well we are definitely using it wrong in that we set the callback twice and hope both callbacks will be called. It is the reason for the comment in LwjglWindow:

because it is overridden in GlfwMouseInput at the line that throws the exception:

i haven’t checked lwjgl code to see what is really causing the problem, but considering it does neither throw that exception on the same platform when called the first time in LwjglWindow nor throw an exception on any other platform when used the way we use it, make it worth to just give commenting out the lines in LwjglWindow that set the callback a shot

1 Like

The callback in the GlfwMouseInput is new in jME 3.5. It is a recent MacOS fix. But why shouldn’t we be able to set up multiple callbacks? They are just listeners on the window handle, is there a limitation on how many callbacks we can register?

I added that comment actually (LwjglWindow.java#L325), it was way before the second callback ever existed.

There is this bug filed about some of these hacks we needed to setup:

I mean it’s “set callback” and not “add callback”.

Either the function is poorly named or it’s meant to have only one, to me.

1 Like

Hmm, you have a point there…

Edit: and quick googling says you are right… (Multiple callbacks · Issue #1185 · glfw/glfw · GitHub ?)

1 Like

I don’t really know (as I have not looked deeply on jme/lwjgl3 code to decide). The error resolves when I downgrade the lwjgl dependencies from 3.3.0 to 3.2.3 so presumably its something wrong or incompatibility of armhf with lwjgl3.3.0 as it works with 3.2.3, jme currently directly uses 3.3.0 when someone add lwjgl3 dependencies.

Then again, there is no corresponding “get” version for this method… but neither is there a way to “remove” one.

…I get sniffs of “API is garbage” here.

Sounds reasonable, but I still wonder why it works when downgrading lwjgl3 version ?

EDIT : Since the exception is NPE then I suppose its armhf which cannot use lwjgl3 to create the window instance.

no its not new in 3.5. it exists since 3.2, while LwjglWindow was added in 3.1 (did not contain the comment back then)

I have no idea, quite a few things have changed between 3.2.3 and 3.3.0, not only in lwjgl, but their dependencies were updated also, so it might be a difference in the glfw versions for example. i just thought its worth a try because that try is way faster than checking everything that changed in the update

1 Like

Hmm, yeah, my memory did a number on me. I remembered this fix incorrect input cursor position on MacOS with retina screen in use by jmecn · Pull Request #1607 · jMonkeyEngine/jmonkeyengine · GitHub. But yes, you are right. We should check that how these callbacks really work.

Well another guess, the behavior of the GLFW callbacks might have been changed since lwjgl-3.3.0 on arm32 GLFW and that points us to look for differences between lwjgl-3.3.0-GLFW and lwjgl-3.2.3-GLFW docs or for any notices about arm systems or something.

I noticed a variation in adapter definitions here and lwjgl3.2.3 on the image. For example the adapter is Null ?

Open an issue at GitHub, please:

1 Like

I think we might need to change the versions of lwjgl3 to lwjgl-3.2.3 for armhf devices, so others using gradle on the pi won’t face this problem (if there is really someone who cares about pi), for me i currently use lwjgl-3.2.3 jars because i stopped using gradle on the pi, but for gradle users, jme forces them to use lwjgl-3.3.0 which will cause this faulty bad window error.

1 Like

False.

JME depends on it by default. Gradle users are 100% free to override this to whatever version they like. They just need to know to do it.

2 Likes

How to do it ? I really don’t know :slightly_smiling_face:, so may be configurations.exclude lwjgl3.3.0 then add the lwjgl3.2.3 ?

1 Like