Same Minie code fails on one machine, but works on others: NoSuchMethodError

Troubleshooting physics
1

Hey All!

I summon you @sgold :smiley: I’m using minie library in my project and it’s absolutely fantastic. However I ran into an issue which I can’t seem to resolve, so I decided to go directly to the author.

TL;DR is that I get the following error when trying to start the application but only on one Linux machine. On another Linux machine (same OS) and on Windows it works fine. Have you ever seen anything like this? Detailed explanation below.

Apr 23, 2024 8:34:55 PM com.jme3.app.LegacyApplication handleError
SEVERE: Uncaught exception thrown in Thread[jME3 Main,5,main]
java.lang.NoSuchMethodError: notifyCollisionGroupListeners_native
	at com.jme3.bullet.PhysicsSpace.createPhysicsSpace(Native Method)
	at com.jme3.bullet.PhysicsSpace.create(PhysicsSpace.java:1114)
	at com.jme3.bullet.CollisionSpace.<init>(CollisionSpace.java:165)
	at com.jme3.bullet.PhysicsSpace.<init>(PhysicsSpace.java:250)
	at com.jme3.bullet.BulletAppState.createPhysicsSpace(BulletAppState.java:717)
	at com.jme3.bullet.BulletAppState.startPhysics(BulletAppState.java:643)
	at com.jme3.bullet.BulletAppState.stateAttached(BulletAppState.java:884)
	at com.jme3.app.state.AppStateManager.attach(AppStateManager.java:147)
	at com.game.modules.core.AbstractVoxelWorldState.setupPhysics(AbstractVoxelWorldState.java:316)
	at com.game.modules.core.AbstractVoxelWorldState.initialize(AbstractVoxelWorldState.java:119)
	at com.jme3.app.state.AppStateManager.initializePending(AppStateManager.java:332)
	at com.jme3.app.state.AppStateManager.update(AppStateManager.java:362)
	at com.jme3.app.SimpleApplication.update(SimpleApplication.java:258)
	at com.jme3.system.lwjgl.LwjglWindow.runLoop(LwjglWindow.java:628)
	at com.jme3.system.lwjgl.LwjglWindow.run(LwjglWindow.java:717)
	at java.base/java.lang.Thread.run(Thread.java:840)

I have this game project I’m working on. I literally git clone it to 3 machines, I run the same code and on one of them it fails to start.

  1. Windows 10 Desktop / Temurin JDK 17 - Works fine
  2. Pop! OS 22.04 Laptop / Temurin JDK 17 - Works fine
  3. Pop! OS 22.04 Desktop - Fresh install / Temurin JDK 17 - Fails with error above

Here is my sample code:

<!-- pom.xml -->
<dependency>
    <groupId>com.github.stephengold</groupId>
    <artifactId>Minie</artifactId>
    <version>7.7.0</version> <!-- Also tried to update it to 8.0.0, it has the same result across machines -->
</dependency>

// AbstractVoxelWorldState.java
    private void setupPhysics(AppStateManager stateManager) {
        // This is commented because it was just an attempt to fix the issue but didn't help. I call App.start() so the native library should be loaded.
        // NativeLibraryLoader.loadNativeLibrary("bulletjme", true);
        this.bulletAppState = new BulletAppState();
        stateManager.attach(bulletAppState); // This is line 316, where it fails.
    }

All jme3-bullet dependencies are purged from the project, only Minie is loaded.

1 Like
2

Phew, I feel stupid. I found the error and it was the due to the perfect alignment of the stars:

TL;DR: The reason was a junk file got loaded due to missing git lfs module.

Okay, so the application starts and loads the native libraries as it should.
However since it is a two year old project in constant development, there happens to be some junk files left over here and there. There was a forgotten libbulletjme.so in one of the resources folder from old JBullet times. The native loader found this first instead of the one in the minie jar, registered it and loaded it. Remember I said that the machine the application fails on is a fresh install? So Git was missing the Git LFS extension, so the libbulletjme.so under the resources folder was just a pointer file because Git LFS didn’t load the proper binary file. The other linux machine has git lfs loaded and it loaded the so file. After installing Git LFS and doing git lfs fetch and git lfs checkout everything works normally.

Sorry for bothering you guys with my foolishness.

5 Likes
3

Good ol’ git lfs. “Why is my gradle wrapper .jar file 0 bytes?!?”

4

After writing my post I was the same. I wanted to work on textures until I get a reply but IntelliJ failed to open all of my png files and I was like what the hell is going on. And then I noticed all of the textures are 128 bytes. And while checking the texture files I found the leftover .so file also which was also 128 bytes and I was like ‘nooo waaaayyy it can’t be’.

1 Like
5

I’m glad the mystery got solved quickly.

I don’t use LFS, so I’m unfamiliar with it’s quirks. However, I would expect NativeLibraryLoader to see that the last-modified date of the .so file was ancient and re-extract it from the Minie jar. Am I missing something here?

6

I have looked into it more and I would like to further correct myself. After you replied sgold, I started to create a new empty project to reproduce this problem. However I came to realize that the libbulletjme.so file I’ve talked about is not a leftover in my project after all. Anytime NativeLibraryLoader loads the so file, it will extract it to the root of my project folder. And that’s how it got entangled with Git LFS. I’m trying to reproduce the same problem as before but I have to check back with the results later.

1 Like