Hi,
I am bashing my head trying to understand why my application runs fine on an Android device with 512MB of RAM but crashes on an iOS device with the same amount of RAM, and a tiny voice suggested me that the problem could be the one: stack overflow.
How can I profile my HTML5 project on iOS (on Safari) to find out if the problem is exactly this one? Alternatively, how can I profile my project (on any device) to find out where the stack is being tortured?
Thanks
iOS is historically memory-constrained. The original iPad only allowed like 96MB of memory for an application, I think? The only method of profiling iOS Safari (that I know of) is to hook it up to a Mac and to use OS X Safari debug tools, it might report errors?
All my OpenFL apps also crashes on iOS browser.
And like @GiG I think about high memory usage.
Than I profile one of app using Chrome profiler, and found that memory usage is really small - about 2 - 3 mb.
After that I get crash reports from device (using iTunes), and found that browser crashed somewhere inside javascript engine.
I tried to debug app (by remove connect to Mac), and strange thing happened - in debug mode app work perfectly, without any crashes.
Also I tested app on various iOS devices, and found that it crashes on iPhone 4, iPhone 4S, sometime on iPhone 5. But never crash on iPhone 6, iPad 2 and iPad2 Air (not sure about iPad 1, it was long ago).
To solve this problem we decided to release native iOS apps, because native app work better and without problems.
My final thoughts:
Craches can be related to high memory usage, but there is another possible reason.
Second reason - bug inside JIT optimizer in iOS Safari.
Why do I think so? Because app work when remote debugger is connected (probably javascript optimizations were disabled in that case) and crashes when run directly, without debugger.
@singmajesty
I managed to get a Mac to use Safari debug tools, but when JS crashes it reloads the page and everything resets, so I can’t see exactly what happened
@restorer
Exactly! JS crashes on iPad Mini 1 and iPhone 4: on iPhone 5, iPad Air and later everything works ok. I think that iOS sets different constraints for stack depending on available RAM, as both iPad Mini 1 and iPhone 4 have 512MBs of RAM.
What do you mean with “size”? If you mean resources weight then the answer is no, because we are optimizing resources size but crashes do not stop.
If you mean the number of files, well… we are in the s**t because the project is going to grow up in the near future…
I am not sure about the real cause of the crashes, but I am pretty sure it is related to stack overflow, the project creates more dynamic data/variables than allowed, and this means that iOS limitations for these devices are terrible!
I meant size of project. Both of the above are smaller projects, which hit on different features (like touch events and sound), but if they work properly, then it at least rules out something basic
Some kind of.
It is not like: if (project.size < SOME_VALUE) { work_normally(); } else { crash(); }
It crashes randomly, at random time, at random places.
App can work for first minute, than crash.
Another time app can crash immediately.
Yet another time app may work for 30 seconds.
etc.
AddingText, BunnyMark, DisplayingABitmap, PiratePig, PlayingSound, SimpleBox2D - probably works (I don’t test is too much).
NyanCat - work for first 20-30 seconds, than crash.
As you can see, NyanCat size is smaller than PiratePig, but PiratePig works (probably), and NyanCat crashes.
Probably that may be related even to Haxe-generated javascript code, not to OpenFL itself…
P. S. for @GiG: Currently I have to modify index.html:
<div id="device-not-supported" style="display:none;">
<div id="device-not-supported-text">
<strong>Sorry :(</strong><br />
It will not work on this phone.<br />
<br />
Try to use PC or Mac.
</div>
</div>
<script type="text/javascript">
if (navigator.userAgent.match(/iPhone/i)) {
setTimeout(function() {
document.getElementById('device-not-supported').style.display = '';
}, 1);
} else {
lime.embed("openfl-content", 0, 0, "321149");
}
</script>
plus some css styles for #device-not-supported and #device-not-supported-text
So it is not stack overflow for sure, Nyan Cat is just a frame sequence…
I don’t think it is a Haxe-generated JS problem, because it works ok on Android and on … iPhone >=5 and iPad >=Air, on the same iOS version!
This is a mysterious mystery.
I can’t modify index that way, because I should inhibit older iPhones/iPads only, I should distinguish between versions, is it possible?
So the smallest sample we can use to reproduce the issue is going to help us.
Does “PiratePig” work, or does it crash? Does any other simpler project crash?
If “PiratePig” works, but “NyanCat” does not, it may have something to do with changing the single surface, or some other thing related to canvas, or memory use.