[SOLVED] JVM crash in Stranded

Yes, sure. It’s a really simple 3d model I don’t think anyone would try to take profit out of it

1 Like

Thank you.
I’m making progress on this issue, but slowly. Having a simple test case has been very helpful!

1 Like

I’ve read what you’ve been posting on the issue and I think the progress is absolutely awesome! Hope you can get to solve it soon. Keep the good work and thanks for the minie library :wink:

1 Like

@joliver82:
I think I’ve addressed the serialization bugs you encountered in Minie-8.0.0. At least, I’m able to run your test code (on either test model) on Windows 11 without crashing.

I’m not yet ready to publish a new release of Minie. If you’d like to verify the fixes, build and install a local snapshot of Minie by cloning the public repo and executing gradlew install.

3 Likes

Yes, sure, I’ll give it a try tomorrow and get back with the results. Are the changes in master or in any other branch?

1 Like

They’re in the “master” branch.

1 Like

I spent some time trying it tonight and I’m sorry to give you bad news… it’s not fully working, now there’re a lot more loading issues.

I’ve tried the following:

Loading gltf and saving j3o from windows (previously failing) → OK
Load the newly created j3o files → Fail
Loading my previous j3o files (generated with minie 4.2.0) → Most of them fail

I’m copying you the output from both OSs

Windows:

#
# A fatal error has been detected by the Java Runtime Environment:
#
#  EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x00007ffc30d047cf, pid=28348, tid=0x00000000000068c4
#
# JRE version: Java(TM) SE Runtime Environment (8.0_161-b12) (build 1.8.0_161-b12)
# Java VM: Java HotSpot(TM) 64-Bit Server VM (25.161-b12 mixed mode windows-amd64 compressed oops)
# Problematic frame:
# C  [bulletjme.dll+0x1447cf]
#
# Failed to write core dump. Minidumps are not enabled by default on client versions of Windows
#
# If you would like to submit a bug report, please visit:
#   http://bugreport.java.com/bugreport/crash.jsp
# The crash happened outside the Java Virtual Machine in native code.
# See problematic frame for where to report the bug.
#

---------------  T H R E A D  ---------------

Current thread (0x000000003961a000):  JavaThread "Thread-11" [_thread_in_native, id=26820, stack(0x000000003ff70000,0x0000000040070000)]

siginfo: ExceptionCode=0xc0000005, reading address 0x0000000000000048

Registers:
RAX=0x0000a147061b4857, RBX=0x000000004006d770, RCX=0x0000000000000000, RDX=0x000000004006d5d0
RSP=0x000000004006d4c0, RBP=0x0000000000000000, RSI=0xfffffffffa7b2ca0, RDI=0x000000003a820400
R8 =0x000000004006d680, R9 =0x000000004006d670, R10=0x00007ffc30d90bb8, R11=0x000000004006d5a8
R12=0x0000000000000000, R13=0x000000003cdc5cf0, R14=0x000000004006d8d0, R15=0x000000003961a000
RIP=0x00007ffc30d047cf, EFLAGS=0x0000000000010202

Top of Stack: (sp=0x000000004006d4c0)
0x000000004006d4c0:   0000000000000003 000000005a66695d
0x000000004006d4d0:   0000000024f017e0 000000000253b8e0
0x000000004006d4e0:   000000071af11290 000000005a4ffbe2
0x000000004006d4f0:   000000004006d6e0 000000005a66744a
0x000000004006d500:   0000000000000000 0000000040717d90
0x000000004006d510:   0000a147061b4857 0000000000000000
0x000000004006d520:   000000000253b8e0 000000005a666f62
0x000000004006d530:   000000000000000b 000000005a66695d
0x000000004006d540:   000000003f800000 0000000000000000
0x000000004006d550:   000000071af11290 00007ffc30c07a82
0x000000004006d560:   000000004006d6e0 000000005a66753d
0x000000004006d570:   0000000024f017e0 000000004006d610
0x000000004006d580:   0000000000000043 000000003961a000
0x000000004006d590:   000000004006d8d0 000000003a820400
0x000000004006d5a0:   fffffffffa7b2ca0 00007ffc30caafa9
0x000000004006d5b0:   000000004006d5e8 000000004006d5f0 

Instructions: (pc=0x00007ffc30d047cf)
0x00007ffc30d047af:   cc 4c 8b dc 56 57 41 56 41 57 48 81 ec c8 00 00
0x00007ffc30d047bf:   00 48 8b 05 f9 08 0e 00 48 33 c4 48 89 44 24 50
0x00007ffc30d047cf:   80 79 48 00 4d 8b f1 49 8b f0 4c 8b fa 48 8b f9
0x00007ffc30d047df:   0f 84 31 02 00 00 41 0f 28 10 f3 0f 10 41 10 0f 


Register to memory mapping:

RAX=0x0000a147061b4857 is an unknown value
RBX=0x000000004006d770 is pointing into the stack for thread: 0x000000003961a000
RCX=0x0000000000000000 is an unknown value
RDX=0x000000004006d5d0 is pointing into the stack for thread: 0x000000003961a000
RSP=0x000000004006d4c0 is pointing into the stack for thread: 0x000000003961a000
RBP=0x0000000000000000 is an unknown value
RSI=0xfffffffffa7b2ca0 is an unknown value
RDI=0x000000003a820400 is an unknown value
R8 =0x000000004006d680 is pointing into the stack for thread: 0x000000003961a000
R9 =0x000000004006d670 is pointing into the stack for thread: 0x000000003961a000
R10=0x00007ffc30d90bb8 is an unknown value
R11=0x000000004006d5a8 is pointing into the stack for thread: 0x000000003961a000
R12=0x0000000000000000 is an unknown value
R13={method} {0x000000003cdc5cf8} 'setLocalScaling' '(JLcom/jme3/math/Vector3f;)V' in 'com/jme3/bullet/collision/shapes/CollisionShape'
R14=0x000000004006d8d0 is pointing into the stack for thread: 0x000000003961a000
R15=0x000000003961a000 is a thread


Stack: [0x000000003ff70000,0x0000000040070000],  sp=0x000000004006d4c0,  free space=1013k
Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)

Java frames: (J=compiled Java code, j=interpreted, Vv=VM code)
j  com.jme3.bullet.collision.shapes.CollisionShape.setLocalScaling(JLcom/jme3/math/Vector3f;)V+0
j  com.jme3.bullet.collision.shapes.CollisionShape.setScale(Lcom/jme3/math/Vector3f;)V+83
j  com.jme3.bullet.collision.shapes.MeshCollisionShape.setScale(Lcom/jme3/math/Vector3f;)V+2
j  com.jme3.bullet.collision.shapes.MeshCollisionShape.createShape()V+181
j  com.jme3.bullet.collision.shapes.MeshCollisionShape.read(Lcom/jme3/export/JmeImporter;)V+113
j  com.jme3.export.binary.BinaryImporter.readObject(I)Lcom/jme3/export/Savable;+235
j  com.jme3.export.binary.BinaryInputCapsule.readSavable(Ljava/lang/String;Lcom/jme3/export/Savable;)Lcom/jme3/export/Savable;+81
j  com.jme3.bullet.collision.shapes.infos.ChildCollisionShape.read(Lcom/jme3/export/JmeImporter;)V+64
j  com.jme3.export.binary.BinaryImporter.readObject(I)Lcom/jme3/export/Savable;+235
j  com.jme3.export.binary.BinaryInputCapsule.resolveIDs([Ljava/lang/Object;)[Lcom/jme3/export/Savable;+42
j  com.jme3.export.binary.BinaryInputCapsule.readSavableArray(Ljava/lang/String;[Lcom/jme3/export/Savable;)[Lcom/jme3/export/Savable;+68
j  com.jme3.export.binary.BinaryInputCapsule.readSavableArrayList(Ljava/lang/String;Ljava/util/ArrayList;)Ljava/util/ArrayList;+65
j  com.jme3.bullet.collision.shapes.CompoundCollisionShape.read(Lcom/jme3/export/JmeImporter;)V+18
j  com.jme3.export.binary.BinaryImporter.readObject(I)Lcom/jme3/export/Savable;+235
j  com.jme3.export.binary.BinaryInputCapsule.resolveIDs([Ljava/lang/Object;)[Lcom/jme3/export/Savable;+42
j  com.jme3.export.binary.BinaryInputCapsule.readStringSavableMap(Ljava/lang/String;Ljava/util/Map;)Ljava/util/Map;+75
j  com.jme3.scene.Spatial.read(Lcom/jme3/export/JmeImporter;)V+250
j  com.jme3.scene.Node.read(Lcom/jme3/export/JmeImporter;)V+79
j  com.jme3.export.binary.BinaryImporter.readObject(I)Lcom/jme3/export/Savable;+235
j  com.jme3.export.binary.BinaryImporter.load(Ljava/io/InputStream;Lcom/jme3/export/ReadListener;Ljava/io/ByteArrayOutputStream;)Lcom/jme3/export/Savable;+631
j  com.jme3.export.binary.BinaryImporter.load(Ljava/io/InputStream;)Lcom/jme3/export/Savable;+4
j  com.jme3.export.binary.BinaryImporter.load(Lcom/jme3/asset/AssetInfo;)Ljava/lang/Object;+17
j  com.jme3.export.binary.BinaryLoader.load(Lcom/jme3/asset/AssetInfo;)Ljava/lang/Object;+27
j  com.jme3.asset.DesktopAssetManager.loadLocatedAsset(Lcom/jme3/asset/AssetKey;Lcom/jme3/asset/AssetInfo;Lcom/jme3/asset/AssetProcessor;Lcom/jme3/asset/cache/AssetCache;)Ljava/lang/Object;+21
j  com.jme3.asset.DesktopAssetManager.loadAsset(Lcom/jme3/asset/AssetKey;)Ljava/lang/Object;+190
j  com.jme3.asset.DesktopAssetManager.loadModel(Lcom/jme3/asset/ModelKey;)Lcom/jme3/scene/Spatial;+2
j  com.jme3.asset.DesktopAssetManager.loadModel(Ljava/lang/String;)Lcom/jme3/scene/Spatial;+9

Linux:

#
# A fatal error has been detected by the Java Runtime Environment:
#
#  SIGSEGV (0xb) at pc=0x00007f02cdaa1144, pid=3922391, tid=0x00007f02b55f16c0
#
# JRE version: Java(TM) SE Runtime Environment (8.0_161-b12) (build 1.8.0_161-b12)
# Java VM: Java HotSpot(TM) 64-Bit Server VM (25.161-b12 mixed mode linux-amd64 compressed oops)
# Problematic frame:
# C  [libbulletjme.so+0x2a1144]  btQuantizedBvh::reportAabbOverlappingNodex(btNodeOverlapCallback*, btVector3 const&, btVector3 const&) const+0x14
#
# Failed to write core dump. Core dumps have been disabled. To enable core dumping, try "ulimit -c unlimited" before starting Java again
#
# If you would like to submit a bug report, please visit:
#   http://bugreport.java.com/bugreport/crash.jsp
# The crash happened outside the Java Virtual Machine in native code.
# See problematic frame for where to report the bug.
#

---------------  T H R E A D  ---------------

Current thread (0x00007f024437d800):  JavaThread "Thread-11" [_thread_in_native, id=3922521, stack(0x00007f02b54f2000,0x00007f02b55f2000)]

siginfo: si_signo: 11 (SIGSEGV), si_code: 1 (SEGV_MAPERR), si_addr: 0x0000000000000040

Registers:
RAX=0x0000000000000000, RBX=0x0000000000000000, RCX=0x00007f02b55ee290, RDX=0x00007f02b55ee2a0
RSP=0x00007f02b55ee1b0, RBP=0x00007f0210d9ece0, RSI=0x00007f02b55ee1e0, RDI=0x0000000000000000
R8 =0x00007f02cdd7c950, R9 =0x0000000000000c00, R10=0x00007f02e91d3995, R11=0x0000000000000c00
R12=0x00007f02b55ee2e0, R13=0x00007f02b55ee280, R14=0x00007f02cdd7c030, R15=0x00007f024437d800
RIP=0x00007f02cdaa1144, EFLAGS=0x0000000000010246, CSGSFS=0x002b000000000033, ERR=0x0000000000000004
  TRAPNO=0x000000000000000e

Top of Stack: (sp=0x00007f02b55ee1b0)
0x00007f02b55ee1b0:   3f336000be8e8e01 000000003f28f412
0x00007f02b55ee1c0:   00007f02b55ee440 28e8f310500dc300
0x00007f02b55ee1d0:   0000000e00000040 00007f02cd894541
0x00007f02b55ee1e0:   00007f02cdd7c950 00007f0210d9e8c0
0x00007f02b55ee1f0:   00007f02b55ee2e0 00007f02b55ee360
0x00007f02b55ee200:   00007f02cdd7c030 00007f02cd8474c6
0x00007f02b55ee210:   00000000bf3d7254 00000000bf3d7254
0x00007f02b55ee220:   5d5e0b6b5d5e0b6b 0000000000000000
0x00007f02b55ee230:   dd5e0b6bdd5e0b6b 28e8f310500dc300
0x00007f02b55ee240:   00007f02cdd7c058 00007f02cd847aa2
0x00007f02b55ee250:   dd5e0b6bdd5e0b6b 00007f02b55ee2e0
0x00007f02b55ee260:   5d5e0b6b5d5e0b6b 000000005d5e0b6b
0x00007f02b55ee270:   00007f02cdd7c058 00007f02b55ee2e0
0x00007f02b55ee280:   000000003f800000 0000000000000000
0x00007f02b55ee290:   5d5e0b6b5d5e0b6b 000000005d5e0b6b
0x00007f02b55ee2a0:   dd5e0b6bdd5e0b6b 00000000dd5e0b6b
0x00007f02b55ee2b0:   000000003f800000 0000000000000000
0x00007f02b55ee2c0:   0000000000000000 000000003f3d7254
0x00007f02b55ee2d0:   bf80000000000000 28e8f31000000000
0x00007f02b55ee2e0:   00007f02cdd7c030 0000000000000000
0x00007f02b55ee2f0:   0000000000000000 000000003f800000
0x00007f02b55ee300:   0000000000000000 3f80000000000000
0x00007f02b55ee310:   0000000000000000 0000000000000000
0x00007f02b55ee320:   000000003f800000 0000000000000000
0x00007f02b55ee330:   0000000000000000 3f800000dd5e0b6b
0x00007f02b55ee340:   0000000000000000 00007f0200000000
0x00007f02b55ee350:   00007f02b55ee380 28e8f310500dc300
0x00007f02b55ee360:   00007f0210d9ece0 00007f0210d9ece0
0x00007f02b55ee370:   00007f02b55ee3c0 00007f0210d9ece0
0x00007f02b55ee380:   00007f02b515a6c8 00007f02b55ee430
0x00007f02b55ee390:   00007f024437d800 00007f02cd8994fb
0x00007f02b55ee3a0:   00007f02b515a6c8 00007f024437d9f8 

Instructions: (pc=0x00007f02cdaa1144)
0x00007f02cdaa1124:   1f 44 00 00 f3 c3 66 0f 1f 44 00 00 48 83 ec 28
0x00007f02cdaa1134:   64 48 8b 04 25 28 00 00 00 48 89 44 24 18 31 c0
0x00007f02cdaa1144:   80 7f 40 00 0f 84 62 01 00 00 f3 44 0f 10 47 08
0x00007f02cdaa1154:   41 0f 28 c0 f3 44 0f 10 6f 18 41 0f 28 f5 f3 0f 

Register to memory mapping:

RAX=0x0000000000000000 is an unknown value
RBX=0x0000000000000000 is an unknown value
RCX=0x00007f02b55ee290 is pointing into the stack for thread: 0x00007f024437d800
RDX=0x00007f02b55ee2a0 is pointing into the stack for thread: 0x00007f024437d800
RSP=0x00007f02b55ee1b0 is pointing into the stack for thread: 0x00007f024437d800
RBP=0x00007f0210d9ece0 is an unknown value
RSI=0x00007f02b55ee1e0 is pointing into the stack for thread: 0x00007f024437d800
RDI=0x0000000000000000 is an unknown value
R8 =0x00007f02cdd7c950: <offset 0x57c950> in /home/joliver/jme3/RailRacer/libbulletjme.so at 0x00007f02cd800000
R9 =0x0000000000000c00 is an unknown value
R10=0x00007f02e91d3995 is at entry_point+85 in (nmethod*)0x00007f02e91d37d0
R11=0x0000000000000c00 is an unknown value
R12=0x00007f02b55ee2e0 is pointing into the stack for thread: 0x00007f024437d800
R13=0x00007f02b55ee280 is pointing into the stack for thread: 0x00007f024437d800
R14=0x00007f02cdd7c030: <offset 0x57c030> in /home/joliver/jme3/RailRacer/libbulletjme.so at 0x00007f02cd800000
R15=0x00007f024437d800 is a thread


Stack: [0x00007f02b54f2000,0x00007f02b55f2000],  sp=0x00007f02b55ee1b0,  free space=1008k
Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
C  [libbulletjme.so+0x2a1144]  btQuantizedBvh::reportAabbOverlappingNodex(btNodeOverlapCallback*, btVector3 const&, btVector3 const&) const+0x14

Java frames: (J=compiled Java code, j=interpreted, Vv=VM code)
J 3822  com.jme3.bullet.collision.shapes.CollisionShape.setLocalScaling(JLcom/jme3/math/Vector3f;)V (0 bytes) @ 0x00007f02e91d3995 [0x00007f02e91d3940+0x55]
J 3866 C1 com.jme3.bullet.collision.shapes.CollisionShape.setScale(Lcom/jme3/math/Vector3f;)V (108 bytes) @ 0x00007f02e970ad14 [0x00007f02e970a720+0x5f4]
J 4585 C1 com.jme3.bullet.collision.shapes.MeshCollisionShape.createShape()V (339 bytes) @ 0x00007f02e9a24fb4 [0x00007f02e9a24260+0xd54]
j  com.jme3.bullet.collision.shapes.MeshCollisionShape.read(Lcom/jme3/export/JmeImporter;)V+113
J 4678 C2 com.jme3.export.binary.BinaryImporter.readObject(I)Lcom/jme3/export/Savable; (279 bytes) @ 0x00007f02e9d7a390 [0x00007f02e9d78980+0x1a10]
J 4704 C1 com.jme3.export.binary.BinaryInputCapsule.readSavable(Ljava/lang/String;Lcom/jme3/export/Savable;)Lcom/jme3/export/Savable; (111 bytes) @ 0x00007f02e97c13e4 [0x00007f02e97c09a0+0xa44]
j  com.jme3.bullet.collision.shapes.infos.ChildCollisionShape.read(Lcom/jme3/export/JmeImporter;)V+64
J 4678 C2 com.jme3.export.binary.BinaryImporter.readObject(I)Lcom/jme3/export/Savable; (279 bytes) @ 0x00007f02e9d7a390 [0x00007f02e9d78980+0x1a10]
J 3557 C1 com.jme3.export.binary.BinaryInputCapsule.resolveIDs([Ljava/lang/Object;)[Lcom/jme3/export/Savable; (60 bytes) @ 0x00007f02e9ae74cc [0x00007f02e9ae7360+0x16c]
J 3653 C1 com.jme3.export.binary.BinaryInputCapsule.readSavableArray(Ljava/lang/String;[Lcom/jme3/export/Savable;)[Lcom/jme3/export/Savable; (98 bytes) @ 0x00007f02e9b35284 [0x00007f02e9b35020+0x264]
J 3670 C1 com.jme3.export.binary.BinaryInputCapsule.readSavableArrayList(Ljava/lang/String;Ljava/util/ArrayList;)Ljava/util/ArrayList; (101 bytes) @ 0x00007f02e9b3b4e4 [0x00007f02e9b3b2a0+0x244]
j  com.jme3.bullet.collision.shapes.CompoundCollisionShape.read(Lcom/jme3/export/JmeImporter;)V+18
J 4678 C2 com.jme3.export.binary.BinaryImporter.readObject(I)Lcom/jme3/export/Savable; (279 bytes) @ 0x00007f02e9d7a390 [0x00007f02e9d78980+0x1a10]
J 3557 C1 com.jme3.export.binary.BinaryInputCapsule.resolveIDs([Ljava/lang/Object;)[Lcom/jme3/export/Savable; (60 bytes) @ 0x00007f02e9ae74cc [0x00007f02e9ae7360+0x16c]
j  com.jme3.export.binary.BinaryInputCapsule.readStringSavableMap(Ljava/lang/String;Ljava/util/Map;)Ljava/util/Map;+75
J 4838 C1 com.jme3.scene.Spatial.read(Lcom/jme3/export/JmeImporter;)V (262 bytes) @ 0x00007f02e94666bc [0x00007f02e9464920+0x1d9c]
j  com.jme3.scene.Node.read(Lcom/jme3/export/JmeImporter;)V+79
J 4678 C2 com.jme3.export.binary.BinaryImporter.readObject(I)Lcom/jme3/export/Savable; (279 bytes) @ 0x00007f02e9d7a390 [0x00007f02e9d78980+0x1a10]
J 3632 C1 com.jme3.export.binary.BinaryImporter.load(Ljava/io/InputStream;Lcom/jme3/export/ReadListener;Ljava/io/ByteArrayOutputStream;)Lcom/jme3/export/Savable; (709 bytes) @ 0x00007f02e9b2bd84 [0x00007f02e9b2a1a0+0x1be4]
j  com.jme3.export.binary.BinaryImporter.load(Ljava/io/InputStream;)Lcom/jme3/export/Savable;+4
j  com.jme3.export.binary.BinaryImporter.load(Lcom/jme3/asset/AssetInfo;)Ljava/lang/Object;+17
j  com.jme3.export.binary.BinaryLoader.load(Lcom/jme3/asset/AssetInfo;)Ljava/lang/Object;+27
J 3737 C1 com.jme3.asset.DesktopAssetManager.loadLocatedAsset(Lcom/jme3/asset/AssetKey;Lcom/jme3/asset/AssetInfo;Lcom/jme3/asset/AssetProcessor;Lcom/jme3/asset/cache/AssetCache;)Ljava/lang/Object; (250 bytes) @ 0x00007f02e94d91e4 [0x00007f02e94d9040+0x1a4]
J 3865 C1 com.jme3.asset.DesktopAssetManager.loadAsset(Lcom/jme3/asset/AssetKey;)Ljava/lang/Object; (221 bytes) @ 0x00007f02e9297edc [0x00007f02e92978e0+0x5fc]
j  com.jme3.asset.DesktopAssetManager.loadModel(Lcom/jme3/asset/ModelKey;)Lcom/jme3/scene/Spatial;+2
j  com.jme3.asset.DesktopAssetManager.loadModel(Ljava/lang/String;)Lcom/jme3/scene/Spatial;+9
3 Likes

Thanks for the follow up. Now that saving to J3O is working—or at least not crashing—I need to figure out why loading from new J3Os doesn’t work. (I’m pessimistic about loading from old J3Os.)

I’ve noticed one issue already: sometimes when I serialize a BoundingValueHierarchy and then immediately de-serialize it, the number of nodes in the hierarchy decreases. The good news is: I can investigate this using GDB on Linux, which is where I’m most comfortable debugging with native code. Also, I’m getting very familiar with Bullet’s BVH code!

It’s interesting the new crashes (during loads) are both in setLocalScaling(). That’s a new place.

I’d also like to understand why the number of bytes in a serialized BVH varies from platform to platform.

5 Likes

I realized I was counting nodes inaccurately, relying on array sizes instead of the m_curNodeIndex field. Solution at 8a74234.

I uncovered two contributing factors:

  1. btQuantizedBvh contains pointers, which are 4 bytes on 32-bit platforms and 8 bytes on 64-bit platforms.
  2. The offset of the first declared field (m_bvhAabbMin) varies between platforms, apparently because they reserve different amounts of memory for the virtual table.

To follow my progress, watch issue 42.

3 Likes

Now I’m working on a solution for the crashes while loading: issue 43

4 Likes

@joliver82 :
I believe Minie issue 43 is solved.
The solution is committed to the “master” branch in my public repo.
When you have time, please test whether the solution allows you to load newly created j3o files.

4 Likes

Great! Thanks :wink: I’ll test it and post the results for both linux and windows

1 Like

Just tested it and it works like a charm. I’ve tested more less the same as in the previous attempt

Loading gltf and saving j3o from windows → OK
Load the newly created j3o files from windows → OK
Loading my previous j3o files (generated with minie 4.2.0) from both linux and windows → OK

I’m sorry I don’t have a running OSX to test it also there

Thanks for the awesome work fixing this :wink:

3 Likes

Thanks for reporting the issue and cooperating with the investigation.
Believe it or not, I had fun.
I’ve closed issue 43.
I hope to publish a new release of Minie soon.

3 Likes

it was not my report, I just gave you some more details and also a simple test case :stuck_out_tongue:

I’m glad you enjoyed it. I find physics a really hard topic moreover mixing java and native code although could be fun to work with that :wink:

I had some extra spare time and I tested master on android and I can confirm that all j3o files are loaded properly. But I’m facing a new issue in android, the app crashes when I try to move an object in the track editor I implemented for the game (yes, it’s somehow physics based) I’m getting the following output:

W/com.jme3.bullet.PhysicsSpace: ADVERTENCIA invoked from wrong thread
A/games.railrace: java_vm_ext.cc:577] JNI DETECTED ERROR IN APPLICATION: JNI NewLocalRef called with pending exception java.lang.AssertionError: wrong thread
    java_vm_ext.cc:577]   at void com.jme3.bullet.PhysicsSpace.preTick(float) (PhysicsSpace.java:1429)
    java_vm_ext.cc:577]   at void com.jme3.bullet.PhysicsSpace.stepSimulation(long, float, int, float, boolean, boolean, boolean) (PhysicsSpace.java:-2)
    java_vm_ext.cc:577]   at void com.jme3.bullet.PhysicsSpace.update(float, int, boolean, boolean, boolean) (PhysicsSpace.java:1020)
    java_vm_ext.cc:577]   at void com.jme3.bullet.DefaultContactManager.update(float, int) (DefaultContactManager.java:314)
    java_vm_ext.cc:577]   at void com.jme3.bullet.PhysicsSpace.update(float, int) (PhysicsSpace.java:992)
    java_vm_ext.cc:577]   at void networkwebgames.railracer.states.TrackEditorState.checkErrorTrackScenographies() (TrackEditorState.java:3469)
    java_vm_ext.cc:577]   at void networkwebgames.railracer.states.TrackEditorState.simpleUpdate(float) (TrackEditorState.java:948)
    java_vm_ext.cc:577]   at void networkwebgames.common.state.SimpleState.update(float) (SimpleState.java:187)
    java_vm_ext.cc:577]   at void com.jme3.app.state.AppStateManager.update(float) (AppStateManager.java:371)
    java_vm_ext.cc:577]   at void networkwebgames.railracer.Main.update() (Main.java:831)
    java_vm_ext.cc:577]   at void com.jme3.app.AndroidHarnessFragment.update() (AndroidHarnessFragment.java:582)
    java_vm_ext.cc:577]   at void com.jme3.system.android.OGLESContext.onDrawFrame(javax.microedition.khronos.opengles.GL10) (OGLESContext.java:366)
    java_vm_ext.cc:577]   at void android.opengl.GLSurfaceView$GLThread.guardedRun() (GLSurfaceView.java:1581)
    java_vm_ext.cc:577]   at void android.opengl.GLSurfaceView$GLThread.run() (GLSurfaceView.java:1280)
    java_vm_ext.cc:577] 
    java_vm_ext.cc:577]     in call to NewLocalRef
    java_vm_ext.cc:577]     from void com.jme3.bullet.PhysicsSpace.stepSimulation(long, float, int, float, boolean, boolean, boolean)

It’s working flawlessly in desktop. I jumped from 4.4.0 to 8.0.0, so I don’t know where this issue first raised. I can test also with other Minie releases to try making your search for the breaking change shorter. Also, if you prefer, I may create a new topic with this because I don’t think this will be related with current issue.

EDIT: forgot to mention that the gameplay works great in all tested platforms including android

1 Like

I jumped from 4.4.0 to 8.0.0, so I don’t know where this issue first raised. I can test also with other Minie releases to try making your search for the breaking change shorter.

I’m curious which version of Minie first triggers the issue. Very likely it’s 7.3.0+for36, which added that check in preTick().

Probably the Android app created the physics space on one thread and later stepped the simulation on a different thread. That’s not allowed.

ok, I’ll check with 7.3.0 and the previous one and get back to you. How about not happening in desktop? Isn’t it weird? I mean, my code is the same for all platforms and not doing anything specific in the android side, everything is inside jme3 APIs…

EDIT: what’s the required jme3 release for Minie 7.2.0? Will it run with jme3.6?

1 Like

How about not happening in desktop?

I’m not an Android developer, but I assume the structure of the Android app differs from a desktop app. Does Android spawn a new thread some time after intialization?

what’s the required jme3 release for Minie 7.2.0?

Minie v7.2.0 was built for jme3-core v3.5.2-stable, but as I recall the differences between v3.5 and v3.6 did not impact Minie. Minie v7.2.0 should work fine with JME 3.6.x .

For further info, see the Minie documentation.

You were right, it started to fail on 7.3.0. The issue in my app was caused by manually calling “bulletAppState.getPhysicsSpace().update” manually having set threading type to parallel. Either changing the threading type to sequential or using TickListener solved it. But why did it just happen in android and not other platforms? Is the preTick() check platform specific or something? Thanks

1 Like

Probably on desktop, safe garbage was happening… ie: garbage that is bad but does not make the app crash. On Android, things are a lot tighter as everything is native there… so garbage is much worse.

You can do a lot of threading sin on Java desktop with only “that’s weird” sort of problems. In a native app, you might as well take an ice poker to memory.