Bug 185608 – REGRESSION (iOS 11.3) Crash on windy.com, and in the Windy app (jetsam?)

• Status: RESOLVED
• Resolution: FIXED
• Component: JavaScriptCore

[Tomas Slavkovsky]

After upgrade of WebKit in iOS 11.3 & 11.3.1 Safari and webView in our Apache Cordova app started to crash. The crash occurs in iPhone on this URL [1] and also on the page inside the Cordova App [3].

Part of the JS that renders this component uses safe and old prooven ES5 only Javascript and uses canvas to render two big retina graphs.

When we connect iPhone Safari to remote debugger the bug does not occur. Standalone iPhone crashes on most of the occasions.

We are not 100% sure that bug is related to Canvas element or JS around it, but we suspect Canvas.

On a thread in our community forum [2] you can find a screen video of the bug. 

How to reproduce the bug:
1. On your iPhone in Safari open www.windy.com or app Windy [3]
2. Go to the menu (yellow three dots) and on the top of the menu click on “Find my location”
3. On picker in the map click to open the detail forecast
4. In detail forecast click airgram
5. In standard behavior, it will open airgram. However, now it stays in the loop and it is trying to open the page again and again. 



[1] https://www.windy.com/
[2] https://community.windy.com/topic/5780/ios-airgram-malfuction-on-iphone-ipad
[3] https://itunes.apple.com/cz/app/windy-wind-and-waves-forecast/id1161387262

[Tomas Slavkovsky]

We found where it fails. It is on entry into the imageData field. Everytime it fails on a different place. Image has size 500x2000px.

Here is the code:

var w = nx * sx
            , imageData = ctx.createImageData( w, h )
            , data = imageData.data

            var p = 0
            , len = ( data.length - 4 ) // last item

            for( j = 0; j < h; j++ ) {

                if(p >= len) break

                for( i = 0; i < w; i++ ) {

                    if(p >= len) break

                    o = j * w + i

                    var br = 1.0

                    if( (j > 0) && (j < (h - 1)) && (i > 0) && (i < w - 1) ) {
                        br = this.edge( dst, w, o )
                    }

                    var rgb = this.steps_[ dst[o] ] || [0, 0, 0]

                    if( br < 0.99 ) {
                        data[p++] = Math.round(rgb[0] * br)
                        data[p++] = Math.round(rgb[1] * br)
                        data[p++] = Math.round(rgb[2] * br)
                    }
                    else if( br > 2.0 ) {
                        data[p++] = Math.min(rgb[0] + br, 255)
                        data[p++] = Math.min(rgb[1] + br, 255)
                        data[p++] = Math.min(rgb[2] + br, 255)
                    }
                    else {
                        data[p++] = rgb[0]
                        data[p++] = rgb[1]
                        data[p++] = rgb[2]
                    }
                    data[p++] = 255;

                }

            }

[Tomas Slavkovsky]

This is what xCode writes when it crash:

2018-05-14 18:56:10.293185+0200 Windy[904:179798] [ProcessSuspension]  0x1c0c6d180 - ProcessAssertion() Unable to acquire assertion for process with PID 0

[Radar WebKit Bug Importer]

<rdar://problem/40257897>

[Simon Fraser (smfr)]

Do you have any crash logs?

[Tomas Slavkovsky]

Unfortunately, not. When you connect it to xcode it works fine.

[Tomas Slavkovsky]

This is the code [1] where it crashes, see the line 287.

[1] https://gist.github.com/ilblog/11863f97f25a4c2478649f5b618fcc16

[Simon Fraser (smfr)]

I think this is probably your process getting killed because it uses too much memory. If you use the Layers panel in the web inspector, you can see that your page uses about 122MB of layer memory in steady state, spiking up to 150MB on interaction. This is really high.

You need to reduce the number of elements on which you apply -webkit-backface-visibility: hidden; and translate3d().

BTW,  -webkit-backface-visibility: hidden; doesn't really do anything any more unless you're really doing 3D.

[Tomas Slavkovsky]

As suggested, we have reduced the number of elements applying -WebKit-backface-visibility: hidden; and translate3d(). However, the airgram is still not working.

[Simon Fraser (smfr)]

By "airgram" you mean the main canvas showing the wind?

[Simon Fraser (smfr)]

Nm, I found the Airgram page.

You're still using too much layer memory here. With the Airgram screen open, you have 145MB of layer memory. Here are some debugging tips:
https://webkit.org/blog/6425/memory-debugging-with-web-inspector/
https://webkit.org/blog/8262/visualizing-layers-in-web-inspector/

[Tomas Slavkovsky]

We have reduced the number of elements and tested it on a test internal server. The result is the same. It's broken something else, so we cannot push it to the production.

[Tomas Slavkovsky]

In our opinion the problem is somewhere in the JIT compiler.

[Simon Fraser (smfr)]

What specific iOS device and OS version are you testing on?

[Tomas Slavkovsky]

the bug started occurring after the release of the iOS 11.3. We are experiencing it on iPhone SE, iPhone 6S and iOS 11.3.1.

[Simon Fraser (smfr)]

I have reproduced, and I agree that it looks like a JIT bug. The crash looks like:

Thread 0 name:  Dispatch queue: com.apple.main-thread
Thread 0 Crashed:
0   ???                           	0x0000000edb98beb4 0 + 63813762740
1   ???                           	0x0000000edbad9054 0 + 63815127124
2   JavaScriptCore                	0x0000000188c7bd20 llint_entry + 29232
3   JavaScriptCore                	0x0000000188c7bd20 llint_entry + 29232
4   JavaScriptCore                	0x0000000188c7bd20 llint_entry + 29232
5   ???                           	0x0000000edb9def6c 0 + 63814102892
6   JavaScriptCore                	0x0000000188c74920 vmEntryToJavaScript + 272
7   JavaScriptCore                	0x0000000189237e98 JSC::JITCode::execute(JSC::VM*, JSC::ProtoCallFrame*) + 184
8   JavaScriptCore                	0x0000000188b7db50 JSC::Interpreter::executeCall(JSC::ExecState*, JSC::JSObject*, JSC::CallType, JSC::CallData const&, JSC::JSValue, JSC::ArgList const&) + 464
9   JavaScriptCore                	0x000000018935fc2c JSC::profiledCall(JSC::ExecState*, JSC::ProfilingReason, JSC::JSValue, JSC::CallType, JSC::CallData const&, JSC::JSValue, JSC::ArgList const&) + 168
10  JavaScriptCore                	0x0000000189415aa8 JSC::JSJobMicrotask::run(JSC::ExecState*) + 488
11  WebCore                       	0x000000018ab49dd0 WebCore::JSDOMWindowMicrotaskCallback::call() + 152

[Simon Fraser (smfr)]

This crash appears to be fixed on trunk. We'll let you know when there's an iOS beta you can test.

[Tomas Slavkovsky]

This bug was fixed by the release of the next iOS version. You can close it now. Thanks