Bug 185608 - REGRESSION (iOS 11.3) Crash on windy.com, and in the Windy app (jetsam?)
Summary: REGRESSION (iOS 11.3) Crash on windy.com, and in the Windy app (jetsam?)
Status: NEW
Alias: None
Product: WebKit
Classification: Unclassified
Component: JavaScriptCore (show other bugs)
Version: Safari 11
Hardware: iPhone / iPad iOS 11
: P2 Critical
Assignee: Nobody
URL: https://www.windy.com
Keywords: InRadar
Depends on:
Blocks:
 
Reported: 2018-05-14 03:54 PDT by Tomas Slavkovsky
Modified: 2018-05-25 12:01 PDT (History)
7 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Tomas Slavkovsky 2018-05-14 03:54:18 PDT
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
Comment 1 Tomas Slavkovsky 2018-05-15 04:43:49 PDT
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;

                }

            }
Comment 2 Tomas Slavkovsky 2018-05-15 07:55:33 PDT
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
Comment 3 Radar WebKit Bug Importer 2018-05-15 08:59:56 PDT
<rdar://problem/40257897>
Comment 4 Simon Fraser (smfr) 2018-05-16 09:24:56 PDT
Do you have any crash logs?
Comment 5 Tomas Slavkovsky 2018-05-17 23:02:01 PDT
Unfortunately, not. When you connect it to xcode it works fine.
Comment 6 Tomas Slavkovsky 2018-05-18 00:51:06 PDT
This is the code [1] where it crashes, see the line 287.

[1] https://gist.github.com/ilblog/11863f97f25a4c2478649f5b618fcc16
Comment 7 Simon Fraser (smfr) 2018-05-18 08:39:51 PDT
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.
Comment 8 Tomas Slavkovsky 2018-05-20 23:46:08 PDT
As suggested, we have reduced the number of elements applying -WebKit-backface-visibility: hidden; and translate3d(). However, the airgram is still not working.
Comment 9 Simon Fraser (smfr) 2018-05-21 10:57:41 PDT
By "airgram" you mean the main canvas showing the wind?
Comment 10 Simon Fraser (smfr) 2018-05-21 11:24:32 PDT
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/
Comment 11 Tomas Slavkovsky 2018-05-22 01:04:00 PDT
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.
Comment 12 Tomas Slavkovsky 2018-05-22 01:56:38 PDT
In our opinion the problem is somewhere in the JIT compiler.
Comment 13 Simon Fraser (smfr) 2018-05-22 08:29:28 PDT
What specific iOS device and OS version are you testing on?
Comment 14 Tomas Slavkovsky 2018-05-22 11:00:14 PDT
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.
Comment 15 Simon Fraser (smfr) 2018-05-23 10:48:28 PDT
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
Comment 16 Simon Fraser (smfr) 2018-05-25 12:01:49 PDT
This crash appears to be fixed on trunk. We'll let you know when there's an iOS beta you can test.