Probable stack overflow of HTML5 on iOS

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 :frowning:

@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.

Does it matter what iOS version the iPhone 4 running? Perhaps this is iOS 6.0 related

It looks like Web Audio and File Upload are two features iOS 6.0 Safari introduced, perhaps this is related to Sound.js and audio?

I think the iOS version is 9.2, I will check this.

Apps crashed on every iOS version from 7.0 up to 9.2
Not sure about 6.0, because I updated my iPhone long time ago, before I started to use OpenFL.

P.S. I think it doesn’t related to audio. It crashed randomly, and when it works (without crash) - audio is playing.

F***ing good, thank you Apple!

P.S.: yes, first I thought it was audio, but removing it nothing changed.

Does it matter the size of the project? PiratePig, DisplayingABitmap, etc?

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.

The same thing for my app - today it work successfully for minute or two

But than BOOM, 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.