Core dump in libbulletjme.so when reading a saved RigidBodyControl

Troubleshooting physics
21

Almost true, but for an error that is repeated multiple times:

fatal error: sys/cdefs.h: No such file or directory

Which is fixed with:

sudo apt-get install gcc-multilib g++-multilib

I tried to add the jme3-bullet-native-3.2.0-SNAPSHOT.jar to the libraries instead of the 3.1.0-beta2 but stills the same issue. However, if I remove it, it stills giving the same issue (just with the jme3-bullet-3.2.0-SNAPSHOT.jar).
The only libs on the projects are: core, lwjgl, desktop, terrain, bullet-3.2.0-SNAPSHOT.

The same issue with all libs replaced by the 3.2 ones.

I’ll try it if I find some time.

22

Ok, it does not crash on windows for me too O.o.

Can you - just to ensure we use exactly the same-
create a selfrunning jar/zip file of project with all stuff in it, so I can run exactly the same code, with exactly the same classes, compilers, binarys?

23

Of course, I’ll do it, but not now, maybe in some hours… or tomorrow (for sure before tuesday). But it is happening in the latest sdk version so I think it should have the exact same libraries, doesn’t it?. The code is just the simple test case I posted, there is no more than that. I’ll try it on windows too btw and see if it is because of the os.

24

Edit: ignore this I think… see bottom.

I was looking at the code because I’m curious that way. While I don’t know much about the issue, I do see something strange.

In CollisionShape.java:

You can see that it reads the scale like it should (and wrote it like it should).

However, note that usually changing the scale requires calling a native method to have it actually take effect:

It seems wrong to me that the local scale is never applied… I also don’t know if that’s dangerous to do before the rest of the mesh data is read. I also don’t know why that would cause a crash because it means the scale of the object would still just be 1,1,1.

…I also don’t know why it would cause a crash for some and not others.

But it definitely seems wrong to me.

Edit: looking at the subclasses like MeshCollisionShape, it creates the shape when it’s done reading and that does set the scale. So I don’t know.

25

Has anyone seeing the error stepped through in the debugger to see exactly which low-level method is crashing?

26

Not me, sorry. I’ve never gone so low-level debugging and currently I’m too busy for it. However, I’m curious to learn about that, just no much time :frowning:

27

Well, next time you have 3 minutes. Run the test case in the debugger. Set a breakpoint on MeshCollisionShape’s read method. “Go”. Then when you reach the break point, step, step, step until crash.

28

Well… this is giving me just the same information as the crash did :S. It crashes at:

public void setScale(Vector3f scale) {
    this.scale.set(scale);
    setLocalScaling(objectId, scale);
}

when setLocalScaling() is called, but it is possible to debug the native code through the debugger?

29

Sorry… I somehow missed the native stack trace when reviewing the thread. I see it now.

30

But can you take a look at the values of scale and objectId?

31

scale: (2, 2, 2), objectId: 139660060829904 (this value changes through execution). It all seems to be right in the java-part.

32

Well… here a project with all the needed libs packed. The only thing missing is the jre. I tried with the one bundled with the sdk and with a system-installed oracle and openjdk versions.

Ok… that was my fault (the compiled .so library was still there between executions)

33

I think I’ve found the problem.

When you load a mesh collision from a j3o, the scaling is applied before the BVH is loaded.

Patch: Fix MeshCollisionShape crash when loaded from j3o · riccardobl/jmonkeyengine@9aba312 · GitHub

1 Like
34

Sounds reasonable, can anyone confirm, this this does not crash anymore?

35

Thanks! :smiley:

Yep, it does not crash anymore and it works as it must.

36

Great, can you @RiccardoBlb make a pullrequest out of it? I will merge it asap then. (plz also make merge request against 3.1 branch, as this should probably be fixed there as well)

37

Ok, I made a slightly different patch with some refactoring on createShape, in this way is cleaner and you don’t have to manually call setScale inside the read method.

PR master: Fix bullet crash when MeshCollisionShape is loaded from j3o by riccardobl · Pull Request #614 · jMonkeyEngine/jmonkeyengine · GitHub
PR 3.1: Fix bullet crash when MeshCollisionShape is loaded from j3o [v3.1] by riccardobl · Pull Request #615 · jMonkeyEngine/jmonkeyengine · GitHub

2 Likes
38

Merged it, thanks. Can everyone who had this issue check if this solved theirs, or if there is something else still creeping around.

39

Just pulled the last version, built, checked that the new code is there and being used, tried and working :+1:

40

Thanks, guys. I was dragging my feet pushing a stable release kind of waiting for this.

So we’ll do a beta4 shortly.