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
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; } }
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
<rdar://problem/40257897>
Do you have any crash logs?
Unfortunately, not. When you connect it to xcode it works fine.
This is the code [1] where it crashes, see the line 287. [1] https://gist.github.com/ilblog/11863f97f25a4c2478649f5b618fcc16
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.
As suggested, we have reduced the number of elements applying -WebKit-backface-visibility: hidden; and translate3d(). However, the airgram is still not working.
By "airgram" you mean the main canvas showing the wind?
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/
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.
In our opinion the problem is somewhere in the JIT compiler.
What specific iOS device and OS version are you testing on?
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.
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
This crash appears to be fixed on trunk. We'll let you know when there's an iOS beta you can test.
This bug was fixed by the release of the next iOS version. You can close it now. Thanks