Hello Guest

libgdx crash

  • 5 Replies
  • 7393 Views
libgdx crash
« on: August 30, 2018, 06:38:54 »
Hi guys.

Just wanted to ask if you are aware this problem described here: https://www.badlogicgames.com/forum/viewtopic.php?f=11&t=27737 and here: https://github.com/libgdx/libgdx/issues/5205
It's a libGDX empty project with lwjgl3 backend.

I have a macbook pro and I get similar error with an empty project:
Code: [Select]
java(91433,0x7fffb7ef8380) malloc: *** error for object 0x12f20d1c0: pointer being freed was not allocated
*** set a breakpoint in malloc_error_break to debug
Disconnected from the target VM, address: '127.0.0.1:59381', transport: 'socket'

Process finished with exit code 134 (interrupted by signal 6: SIGABRT)

I use my macbook (but I don't have any switch in the settings that was mentioned) with external monitor, but if I plug out, the same happens.

Note, that with my own "engine", I have no such problem with lwjgl3.

*

Offline spasi

  • *****
  • 2261
    • WebHotelier
Re: libgdx crash
« Reply #1 on: August 30, 2018, 08:52:07 »
The only double-free bug we've had was fixed long ago. Sounds like a libGDX issue. Should be easy to find what LWJGL APIs are being used in a debug session. Also try running with -Dorg.lwjgl.util.Debug=true -Dorg.lwjgl.util.DebugAllocator=true.

Re: libgdx crash
« Reply #2 on: August 30, 2018, 10:04:38 »
Code: [Select]
[LWJGL] Version: 3.1.3 SNAPSHOT
[LWJGL] OS: Mac OS X v10.13.6
[LWJGL] JRE: 10.0.1 x86_64
[LWJGL] JVM: Java HotSpot(TM) 64-Bit Server VM v10.0.1+10 by "Oracle Corporation"
[LWJGL] Loading library (system): lwjgl
[LWJGL] Found at: /var/folders/h7/9rwdfvvx3dd6xvrj9mjgwzcc0000gn/T/lwjglmudlee/3.1.3-SNAPSHOT/liblwjgl.dylib
[LWJGL] Loaded from org.lwjgl.librarypath: /var/folders/h7/9rwdfvvx3dd6xvrj9mjgwzcc0000gn/T/lwjglmudlee/3.1.3-SNAPSHOT/liblwjgl.dylib
[LWJGL] MemoryUtil accessor: MemoryAccessorUnsafe
[LWJGL] Loading library: jemalloc
[LWJGL] Found at: /var/folders/h7/9rwdfvvx3dd6xvrj9mjgwzcc0000gn/T/lwjglmudlee/3.1.3-SNAPSHOT/libjemalloc.dylib
[LWJGL] Loaded from org.lwjgl.librarypath: /var/folders/h7/9rwdfvvx3dd6xvrj9mjgwzcc0000gn/T/lwjglmudlee/3.1.3-SNAPSHOT/libjemalloc.dylib
[LWJGL] MemoryUtil allocator: DebugAllocator
[LWJGL] Loading library: glfw
[LWJGL] Found at: /var/folders/h7/9rwdfvvx3dd6xvrj9mjgwzcc0000gn/T/lwjglmudlee/3.1.3-SNAPSHOT/libglfw.dylib
[LWJGL] Loaded from org.lwjgl.librarypath: /var/folders/h7/9rwdfvvx3dd6xvrj9mjgwzcc0000gn/T/lwjglmudlee/3.1.3-SNAPSHOT/libglfw.dylib
[LWJGL] Loading library: openal
[LWJGL] Found at: /var/folders/h7/9rwdfvvx3dd6xvrj9mjgwzcc0000gn/T/lwjglmudlee/3.1.3-SNAPSHOT/libopenal.dylib
[LWJGL] Loaded from org.lwjgl.librarypath: /var/folders/h7/9rwdfvvx3dd6xvrj9mjgwzcc0000gn/T/lwjglmudlee/3.1.3-SNAPSHOT/libopenal.dylib
[LWJGL] Loading library: objc
[LWJGL] libobjc.dylib not found in org.lwjgl.librarypath=/var/folders/h7/9rwdfvvx3dd6xvrj9mjgwzcc0000gn/T/lwjglmudlee/3.1.3-SNAPSHOT
[LWJGL] Loaded from system paths
[LWJGL] Loading library (system): lwjgl_opengl
[LWJGL] Found at: /var/folders/h7/9rwdfvvx3dd6xvrj9mjgwzcc0000gn/T/lwjglmudlee/3.1.3-SNAPSHOT/liblwjgl_opengl.dylib
[LWJGL] Loaded from org.lwjgl.librarypath: /var/folders/h7/9rwdfvvx3dd6xvrj9mjgwzcc0000gn/T/lwjglmudlee/3.1.3-SNAPSHOT/liblwjgl_opengl.dylib
[LWJGL] Loading library: com.apple.opengl
[LWJGL] Success
java(95681,0x7fffb7ef8380) malloc: *** error for object 0x133da41c0: pointer being freed was not allocated
*** set a breakpoint in malloc_error_break to debug
Disconnected from the target VM, address: '127.0.0.1:58794', transport: 'socket'

Process finished with exit code 134 (interrupted by signal 6: SIGABRT)

*

Offline spasi

  • *****
  • 2261
    • WebHotelier
Re: libgdx crash
« Reply #3 on: August 30, 2018, 10:21:07 »
Any change if you also pass -Dorg.lwjgl.system.allocator=system?

Re: libgdx crash
« Reply #4 on: August 30, 2018, 10:51:54 »
You got it! with
Code: [Select]
-Dorg.lwjgl.system.allocator=system it does work :) I report it back to the other forums.

*

Offline spasi

  • *****
  • 2261
    • WebHotelier
Re: libgdx crash
« Reply #5 on: August 30, 2018, 10:57:18 »
It would still be useful to identify exactly what sequence of actions and which call causes the crash. It's likely that the bug is still there in libGDX and the system allocator silently accepts it.