Mobile memory issues with Ammo.js

Hello everyone.

As I am back working on a game of mine and I noticed the game crashes very frequently when played from mobile. I am testing it with an iPhone 7. Everything is low-poly and I am quite happy with the frame-rate, however from time to time the tab just crashes. I am guessing this is a memory leak problem.

There is not much dynamic objects instancing and I will surely optimize it with an object pool later on. What I am mainly concerned about, is that the game client runs Ammo.js to simulate the client-side physics. I fear Ammo.js requires too much memory which just causes the game client to crash. Has anyone experienced something similar? I would really appreciate any ideas regarding the matter.

Here is a link to the game : https://gcapsarena.com .

Thanks.

Hey! first thing to try is to compare memory snapshots using F12 memory profiler on your computer

I did it and honestly all seems perfectly fine:

So to help you we need to understand what cause the crash :frowning: Any specific behavior?

Hey,

Thanks for taking the time and diving into my problem.

The problem occurs always if you start a second match on mobile without refreshing. Sometimes it happens in the first match as well. I get no information from it, just a “has stopped” message. When I try from chrome in iphone it happens almost always. I do not get the same problem from Samsung s8 though, I guess because it has more RAM. Any idea how to debug it? Right now I am clueless :confused:

Thanks in advance!

You could try Documentation | Vorlon.JS

It will help you have a remote console

1 Like

Great - thanks, I will try it out.

You could also try this for debugging on iOS:

(appears to be just for logs)

Quick update, it was indeed a memory leak. Seems like engine.dispose and scene.dispose somehow don’t dispose everything since the memory kept growing. I have not fixed it yet though but I’m glad I got a track. Also, ammojs does indeed take up a lot of memory, even though the performance is very good both in mobile and pc.

@Null I am really interested in a repro (sources) cause I hate those and would like to get rid of it ASAP :slight_smile:

I think it might be implementation-specific to my project. Also, I am unfortunately stuck with BJS v. 4.0.0-alpha.21 because the stable version gives : uncaught exception: abort(20). Build with -s ASSERTIONS=1 for more info. when calling physicsImpostor.forceUpdate. Repro to playground : Babylon.js Playground ( not sure if I did it correctly, if yes, check console ). And the latest version, when calling forceUpdate on a sphere impostor, somehow does not reset its movement. I can not seem to repro that though.

This means that the memory leak might be solved in the stable or latest version, I will test, if its something applicable to the latest version I will report. Thanks :slight_smile:

Perfect, adding @trevordev for the phys bug.

Hey guys,

Seems like the audio caused the game to crash, a smaller audio file worked like a charm! I think disposing ammo does not clean up the whole memory but I may be mistaken, maybe it’s the way it works. Thanks for the help!

It seems to me that there have been some changes to forceUpdate () in 4.1.0 by trevor (this is problem that exists in version 4.0 but was fix in 4.1.0)

You have to have the latest version of Babylon as well as the latest version of AmmoJS physics and it should work.

If you change the version of your Playground to Latest, the problem has disappeared :
https://playground.babylonjs.com/index.html#0AR136

See here: what’s new 4.1.0

  • Cannon and Ammo forceUpdate will no longer cause an unexpected exception (TrevorDev)
  • Setting mesh.scaling to a new vector will no longer automatically call forceUpdate (this should be done manually when needed) (TrevorDev)

Thank you Dad72. Yes, it does not give an exception anymore, however, the sphere impostor behaves weirdly for me in the latest version. Maybe it is specific to my project but the sphere does not stop as it should by calling force update, weirdly enough, I could not reproduce the behavior in the playground.