OSX Crash on init()

[Jeddic]

After the Steam Client updated last week (Nov 8th) I found it would crash the jre with the following:

Stack: [0x000070000a94f000,0x000070000aa4f000],  sp=0x000070000aa49d40,  free space=1003k
Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
C  [libjemalloc.dylib+0x5832]
[error occurred during error reporting (printing native stack), id 0xe0000000]

Java frames: (J=compiled Java code, j=interpreted, Vv=VM code)
j  com.codedisaster.steamworks.SteamAPI.nativeInit()Z+0
j  com.codedisaster.steamworks.SteamAPI.init()Z+16
j  com.voxelcraft.states.SteamState.stateAttached(Lcom/jme3/app/state/AppStateManager;)V+3
j  com.jme3.app.state.AppStateManager.attach(Lcom/jme3/app/state/AppState;)Z+31
j  com.voxelcraft.SpoxelClient.simpleInitApp()V+141
j  com.jme3.app.SimpleApplication.initialize()V+282
j  com.jme3.system.lwjgl.LwjglWindow.initInThread()Z+129
j  com.jme3.system.lwjgl.LwjglWindow.run()V+32
j  com.jme3.system.lwjgl.LwjglWindow.create(Z)V+27
j  com.jme3.app.LegacyApplication.start(Lcom/jme3/system/JmeContext$Type;Z)V+92
j  com.jme3.app.LegacyApplication.start()V+5
j  com.jme3.app.SimpleApplication.start()V+51
j  com.voxelcraft.SpoxelClient.main([Ljava/lang/String;)V+138
v  ~StubRoutines::call_stub

So far i've attempted updating to 1.8.0 from 1.7.0 as well as building the 1.8.1-snapshot as well as two separate JRE's with the same result. The existing build of the game i'm working on also crashes and no longer loads. I've replicated this on two separate Macbooks now. So far i've only ran across this on OSX and not Windows.

[code-disaster]

What OS X versions are these MacBooks running on?

[Jeddic]

I've tried on 10.14.1 as well as 10.13.6.

[code-disaster]

This is a weird one. I don't have any issues on my MBP with 10.13.6 and the latest Steam client.

I've seen some mentions of a crash bug with overlays in the Steam beta client, but I assume you do not use that.

The crash in libjemalloc is suspicious. I'm not familiar with JME3. What LWJGL version does your build run on? Maybe try to tell LWJGL to use the system allocator, instead of jemalloc?

[maximiliancsuk]

I've received a similar report from a user as well:

`Stack: [0x00007ffee6bff000,0x00007ffee73ff000],  sp=0x00007ffee73f97d0,  free space=8169k
Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
C  [libjemalloc.dylib+0x5832]
[error occurred during error reporting (printing native stack), id 0xe0000000]

Java frames: (J=compiled Java code, j=interpreted, Vv=VM code)
j  com.codedisaster.steamworks.SteamAPI.nativeInit()Z+0
j  com.codedisaster.steamworks.SteamAPI.init(Ljava/lang/String;)Z+5
j  com.codedisaster.steamworks.SteamAPI.init()Z+1
j  steam.Steam.setup()Z+6
j  hookyourfriends.desktop.SteamPlatformAdapter.setupGame()V+8
j  com.imakegames.hook.HookYourFriends.create()V+204
j  com.badlogic.gdx.backends.lwjgl3.Lwjgl3Window.initializeListener()V+11
j  com.badlogic.gdx.backends.lwjgl3.Lwjgl3Window.update()Z+8
j  com.badlogic.gdx.backends.lwjgl3.Lwjgl3Application.loop()V+101
j  com.badlogic.gdx.backends.lwjgl3.Lwjgl3Application.<init>(Lcom/badlogic/gdx/ApplicationListener;Lcom/badlogic/gdx/backends/lwjgl3/Lwjgl3ApplicationConfiguration;)V+257
j  hookyourfriends.desktop.BaseLauncher.launch([Ljava/lang/String;)V+187
j  hookyourfriends.desktop.SteamLauncher.main([Ljava/lang/String;)V+10
v  ~StubRoutines::call_stub`

On Mac OS X 10.14

[code-disaster]

Well, I'm not sure what to do about this. The wrapper doesn't do much at this point, it just forwards the FFI call.

To me it looks like they (Valve) introduced some memory management bug. If possible, try running with -Dorg.lwjgl.system.allocator=system as a VM parameter. The jemalloc library seems to be more sensitive than the system allocator about such issues.

By the way... it says "10.7-10.10", but who knows:

[Jeddic]

I'm using LWJGL 3.1.5 at the moment. So I played around with this a little bit and using -Dorg.lwjgl.system.allocator=system does allow the game to run. I've update to the Nov 12th client release and this is still a problem. I don't really know enough about the LWJGL3 allocators enough to know how viable changing it is and what the ramifications are.

[code-disaster]

FYI: I've seen (and helped to fix) a memory related crash issue with lwjgl-yoga in the past. In that case, yoga (the native library) mixed up the use of malloc/free and new/delete in C++ code. With the system allocator, this usually doesn't matter, because it's all resolved to the same OS functions anyway. But jemalloc, which hooks into these allocation functions, didn't like the mixup at all and crashed.

This here might be a similar issue, but it's impossible to tell w/o access to the source code. Also, I can't tell if using -Dorg.lwjgl.system.allocator=system is a viable workaround or not. It might be perfectly fine, or just hide or defer the problem.

[maximiliancsuk]

I can confirm that adding -Dorg.lwjgl.system.allocator=system to the VM parameters works and the game doesn't crash anymore. Let's... hope Valve properly fixes this on their end?

[code-disaster]

Honestly, I'd probably go with the system allocator as a default setting. It shouldn't impact performance noticeably, if you don't do crazy stuff. And it's LWJGL3's default on Windows anyway.

[AlrikG]

I had the same problem with Linux and OSX especially when using threads. It worked on Windows. This was a jemalloc bug which is now fixed. Just download the current LWJGL version. But you can also use the system allocator without having to worry.

@code-disaster I think this issue can be closed now.

[code-disaster]

Thank you all for the feedback.