a crash when exiting an overlay scene with a webView (only happens in iOS device testing)

Solar2D Composer
#1

I use a overlay scene to show a webView, and it was working fine so far until recently I added another storyboard that does the same thing, my app crashes when exiting the webView & the overlay scene. (The app exits immediately back to iPhone desktop)

The console log shows:

\<Warning\>: Application 'UIKitApplication:com.test.myapp[0xdb7d]' exited abnormally with signal 11: Segmentation fault: 11

and the crash log shows 

Thread 0 Crashed: 0 libobjc.A.dylib 0x38726b36 objc\_msgSend + 22 1 UIKit 0x30ce7f90 -[UIWebView webView:identifierForInitialRequest:fromDataSource:] + 72 2 CoreFoundation 0x2e358500 \_\_invoking\_\_\_ + 64 3 CoreFoundation 0x2e2a2eb6 -[NSInvocation invoke] + 278 4 CoreFoundation 0x2e2a664e -[NSInvocation invokeWithTarget:] + 46 5 WebKit 0x36b9af7a -[\_WebSafeForwarder forwardInvocation:] + 218 6 CoreFoundation 0x2e35706c \_\_\_forwarding\_\_\_ + 348 7 CoreFoundation 0x2e2a6594 \_CF\_forwarding\_prep\_0 + 20 8 CoreFoundation 0x2e358500 \_\_invoking\_\_\_ + 64 9 CoreFoundation 0x2e2a2eb6 -[NSInvocation invoke] + 278 10 WebCore 0x361ecb88 HandleDelegateSource(void\*) + 96 11 CoreFoundation 0x2e320188 \_\_CFRUNLOOP\_IS\_CALLING\_OUT\_TO\_A\_SOURCE0\_PERFORM\_FUNCTION\_\_ + 12 12 CoreFoundation 0x2e31f656 \_\_CFRunLoopDoSources0 + 202 13 CoreFoundation 0x2e31de4a \_\_CFRunLoopRun + 618 14 CoreFoundation 0x2e288ce2 CFRunLoopRunSpecific + 518 15 CoreFoundation 0x2e288ac6 CFRunLoopRunInMode + 102 16 GraphicsServices 0x32fa927e GSEventRunModal + 134 17 UIKit 0x30b2aa3c UIApplicationMain + 1132 18 myapp 0x00044bf2 \_\_\_lldb\_unnamed\_function1$$myapp + 62 19 myapp 0x00044bac start + 36

Please note that this crash ONLY happens in my iPhone 4S testing. It does NOT happen in Simulator, and it does NOT happen in Galaxy Tab. It’s a very strange crash.

Any thoughts?

#2

Hi Joe,

Is the web view still loading when you attempt to close it? If so, can you try stopping it via the “myWebView:stop()” function, and see if the problem persists?

Thanks,

Brent

#3

After some testing, here are the cases:

(1) add “webView:stop()”, it still crashes.

(2) comment out "webView:addEventListener(“urlRequest”, webListener), the crash does not happen.

(3) added “webView:removeEventListener(“urlRequest”, webListener)” before removing webView, it still crashes.

(4) put “webView:removeEventListener(“urlRequest”, webListener)” in overlay exitScene and remove webView in overlay destroyScene, the crash does not happen.

Final code like this to prevent the crash

function scene:exitScene( event ) &nbsp; &nbsp; local group = self.view &nbsp; &nbsp; webView:removeEventListener("urlRequest", webListener) &nbsp; &nbsp; webView:stop() end

function scene:destroyScene( event ) &nbsp; &nbsp; local group = self.view &nbsp; &nbsp; webView:removeSelf() &nbsp; &nbsp; webView = nil end&nbsp;

It still feels tricky & unstable, is it possible to be fixed at Corona side? It’s hard to show you all of my source code, because the situation happens after I added a couple of storyboard scenes when one of them calls the overlay scene that shows the webView. However, it is not happening in another storyboard that calls the same overlay scene that shows the webView.

#4

You probably should be removing the webView in the exit scene, because there is no guarantee when destoryScene() gets called  (low memory or you get around to calling purgeScene() or removeScene()).   native.* objects should be created in “enterScene” and destroyed by hand in “exitScene”.

#5

Hi Joe,

Is the web view still loading when you attempt to close it? If so, can you try stopping it via the “myWebView:stop()” function, and see if the problem persists?

Thanks,

Brent

#6

After some testing, here are the cases:

(1) add “webView:stop()”, it still crashes.

(2) comment out "webView:addEventListener(“urlRequest”, webListener), the crash does not happen.

(3) added “webView:removeEventListener(“urlRequest”, webListener)” before removing webView, it still crashes.

(4) put “webView:removeEventListener(“urlRequest”, webListener)” in overlay exitScene and remove webView in overlay destroyScene, the crash does not happen.

Final code like this to prevent the crash

function scene:exitScene( event ) &nbsp; &nbsp; local group = self.view &nbsp; &nbsp; webView:removeEventListener("urlRequest", webListener) &nbsp; &nbsp; webView:stop() end

function scene:destroyScene( event ) &nbsp; &nbsp; local group = self.view &nbsp; &nbsp; webView:removeSelf() &nbsp; &nbsp; webView = nil end&nbsp;

It still feels tricky & unstable, is it possible to be fixed at Corona side? It’s hard to show you all of my source code, because the situation happens after I added a couple of storyboard scenes when one of them calls the overlay scene that shows the webView. However, it is not happening in another storyboard that calls the same overlay scene that shows the webView.

#7

You probably should be removing the webView in the exit scene, because there is no guarantee when destoryScene() gets called  (low memory or you get around to calling purgeScene() or removeScene()).   native.* objects should be created in “enterScene” and destroyed by hand in “exitScene”.

#8

I’ve found the same problem in the latest public release (which also happens to be the latest daily build). I filed the crash logs last week as Case 27995. In my case I’m not using an overlay scene, but switching between two standard storyboard scenes. The crash happens after exitScene is called for the outgoing scene, but before enterScene is called for the incoming scene.

Like <joe528> above, I only see this error on iOS devices, not in the OS X simulator or on Android devices.

I’ll try the suggestion above of removing the event listener in exitScene and removing the webview in destroyScene.

Here’s my crash log, which strongly indicates it’s the identical problem that <joe528> came across:

Thread 0 Crashed: 0 &nbsp; libobjc.A.dylib &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;&nbsp;&nbsp;&nbsp;0x38484b66 objc\_msgSend + 6 1 &nbsp; UIKit &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;&nbsp;&nbsp;&nbsp;0x30ad3394 -[UIWebView webView:identifierForInitialRequest:fromDataSource:] + 72 2 &nbsp; CoreFoundation &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;0x2e1303d0 \_\_invoking\_\_\_ + 64 3 &nbsp; CoreFoundation &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;0x2e07a6c2 -[NSInvocation invoke] + 282 4 &nbsp; CoreFoundation &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;0x2e07de7e -[NSInvocation invokeWithTarget:] + 46 5 &nbsp; WebKit &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;0x36a21e2e -[\_WebSafeForwarder forwardInvocation:] + 218 6 &nbsp; CoreFoundation &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;0x2e12ef48 \_\_\_forwarding\_\_\_ + 348 7 &nbsp; CoreFoundation &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;0x2e07ddc4 \_\_forwarding\_prep\_0\_\_\_ + 20 8 &nbsp; CoreFoundation &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;0x2e1303d0 \_\_invoking\_\_\_ + 64 9 &nbsp; CoreFoundation &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;0x2e07a6c2 -[NSInvocation invoke] + 282 10 &nbsp;WebCore &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;&nbsp;&nbsp;&nbsp;0x36078504 HandleDelegateSource(void\*) + 96 11 &nbsp;CoreFoundation &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;0x2e0f7f1c \_\_CFRUNLOOP\_IS\_CALLING\_OUT\_TO\_A\_SOURCE0\_PERFORM\_FUNCTION\_\_ + 12 12 &nbsp;CoreFoundation &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;0x2e0f73e2 \_\_CFRunLoopDoSources0 + 202 13 &nbsp;CoreFoundation &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;0x2e0f5bd2 \_\_CFRunLoopRun + 626 14 &nbsp;CoreFoundation &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;0x2e06046c CFRunLoopRunSpecific + 520 15 &nbsp;CoreFoundation &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;0x2e06024e CFRunLoopRunInMode + 102 16 &nbsp;GraphicsServices &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;0x32d9a2e6 GSEventRunModal + 134 17 &nbsp;UIKit &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;&nbsp;&nbsp;&nbsp;0x30915840 UIApplicationMain + 1132 &nbsp;
#9

After following <joe258>'s suggestion above, I’m tentatively prepared to say it works. (Destroying the webview in the exitscene was not as successful.) I just ran a few dozen scene transitions on a physical iOS device and didn’t see this crash occur. Thanks, folks, for sharing your suggestions.

#10

My app is a reader app so webView is heavily used. I strongly suggest Corona to do more enhancements & improvements to webView module because I’ve found webView might be the weakest link in Corona SDK.

There are many things to be done for this module, for example: it’s always on top, it crashes like the example above, it also crashes in some rare case that my app users reported during leaving an comment in a Facebook page (which I cannot reproduce), it also crashes often in Simulator for certain pages, no “loaded” event in subsequent page requests for iOS, cannot know the current link, cannot do further sharing to other apps, cannot detect touch events, etc. 

#11

I’ve found the same problem in the latest public release (which also happens to be the latest daily build). I filed the crash logs last week as Case 27995. In my case I’m not using an overlay scene, but switching between two standard storyboard scenes. The crash happens after exitScene is called for the outgoing scene, but before enterScene is called for the incoming scene.

Like <joe528> above, I only see this error on iOS devices, not in the OS X simulator or on Android devices.

I’ll try the suggestion above of removing the event listener in exitScene and removing the webview in destroyScene.

Here’s my crash log, which strongly indicates it’s the identical problem that <joe528> came across:

Thread 0 Crashed: 0 &nbsp; libobjc.A.dylib &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;&nbsp;&nbsp;&nbsp;0x38484b66 objc\_msgSend + 6 1 &nbsp; UIKit &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;&nbsp;&nbsp;&nbsp;0x30ad3394 -[UIWebView webView:identifierForInitialRequest:fromDataSource:] + 72 2 &nbsp; CoreFoundation &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;0x2e1303d0 \_\_invoking\_\_\_ + 64 3 &nbsp; CoreFoundation &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;0x2e07a6c2 -[NSInvocation invoke] + 282 4 &nbsp; CoreFoundation &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;0x2e07de7e -[NSInvocation invokeWithTarget:] + 46 5 &nbsp; WebKit &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;0x36a21e2e -[\_WebSafeForwarder forwardInvocation:] + 218 6 &nbsp; CoreFoundation &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;0x2e12ef48 \_\_\_forwarding\_\_\_ + 348 7 &nbsp; CoreFoundation &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;0x2e07ddc4 \_\_forwarding\_prep\_0\_\_\_ + 20 8 &nbsp; CoreFoundation &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;0x2e1303d0 \_\_invoking\_\_\_ + 64 9 &nbsp; CoreFoundation &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;0x2e07a6c2 -[NSInvocation invoke] + 282 10 &nbsp;WebCore &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;&nbsp;&nbsp;&nbsp;0x36078504 HandleDelegateSource(void\*) + 96 11 &nbsp;CoreFoundation &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;0x2e0f7f1c \_\_CFRUNLOOP\_IS\_CALLING\_OUT\_TO\_A\_SOURCE0\_PERFORM\_FUNCTION\_\_ + 12 12 &nbsp;CoreFoundation &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;0x2e0f73e2 \_\_CFRunLoopDoSources0 + 202 13 &nbsp;CoreFoundation &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;0x2e0f5bd2 \_\_CFRunLoopRun + 626 14 &nbsp;CoreFoundation &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;0x2e06046c CFRunLoopRunSpecific + 520 15 &nbsp;CoreFoundation &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;0x2e06024e CFRunLoopRunInMode + 102 16 &nbsp;GraphicsServices &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;0x32d9a2e6 GSEventRunModal + 134 17 &nbsp;UIKit &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;&nbsp;&nbsp;&nbsp;0x30915840 UIApplicationMain + 1132 &nbsp;
#12

After following <joe258>'s suggestion above, I’m tentatively prepared to say it works. (Destroying the webview in the exitscene was not as successful.) I just ran a few dozen scene transitions on a physical iOS device and didn’t see this crash occur. Thanks, folks, for sharing your suggestions.

#13

My app is a reader app so webView is heavily used. I strongly suggest Corona to do more enhancements & improvements to webView module because I’ve found webView might be the weakest link in Corona SDK.

There are many things to be done for this module, for example: it’s always on top, it crashes like the example above, it also crashes in some rare case that my app users reported during leaving an comment in a Facebook page (which I cannot reproduce), it also crashes often in Simulator for certain pages, no “loaded” event in subsequent page requests for iOS, cannot know the current link, cannot do further sharing to other apps, cannot detect touch events, etc. 

#14

I can confirm this crash as well. I have a webview that’s in an overlay scene. I create the webview in willEnterScene and do the following in exitScene:

  1. Stop the webview’s request using stop()
  2. Remove the “urlRequest” event listener
  3. Call removeSelf() on the webview
  4. Set the webview to nil

Even with all of the above, it crashes if I close the webview while it’s loading. Anyone else find a fix? I’m on build 2014.2135.

#15

You should get an event from the webView that lets you know when it’s loaded.  You could disable your back button or whatever you’re doing to trigger the closing of the overlay until you know the webView has loaded. 

What is likely happening is that you’re closing the overlay (and potentially removing it) and the callBack function that triggers when the webView loads ls looking for something that’s no longer in memory and casing your Segment Violation.  This would happen if you have an onComplete on an audio track too. 

Rob

#16

If the app depends on the events to check if it’s loading status or not (in order to disable the back button), I think there are many problems:

(1) It’s a bad user experience. What if the Internet connection is slow? The user has to be waiting for the webView (a blank screen) and cannot do anything, even exiting?

(2) The events from the webView are not that reliable from my experience with it for the last three months. Sometimes there are some event missing and sometimes there are inconsistent patterns. For example, I tried to use events to determine the current link address, but I can only get 90% accuracy because of the inconsistency or missing events. Even after the “loaded” event is added, I still cannot rely on the loaded events to get the current link address for 100% accuracy because the loaded event is missed in some cases. I prefer not to use the loaded event in my case because it has lower than 90% accuracy for me to determine the current link address. 

And if there is some missed event when determining if the webView is loaded, the user is gonna get stuck at this webView forever, terrible user experience.

(3) There are times when I click a link inside a webpage, the page does not show up, and the backward button flag is not set. The webView goes into a weird state. I have implemented a feature to open the current link in Safari, so I try to open the same link in Safari, there is no problem to open that page. So I conclude it’s a problem about the webView. If this happens, another terrible user experience.

I think webView component really needs more attention & more enhancements in its fundamental implementation. This kind of workaround does not (can not) help the webView’s vulnerability.

#17

Hey @Rob,

Thanks for the suggestion, you’re likely right as to what’s happening. However, I agree with @joe528 that it’s bad UX if I have to disable the close button until a page has loaded. Not to mention, in the docs it states:

 There is a known issue on actual iOS devices in which subsequent “loaded” events are not triggered. This is currently being investigated.

Is there anything else that can be tried to close the webview while it’s loading?

#18

@max84 

(1) Have you tried the solution above? (call webView:removeSelf() in destroyScene() instead)

I have no problem to close the webView here. There is no crash even if it’s in loading state.

(2) About the documentation saying subsequent “loaded” events are not triggered. According to Corona, they have fixed this issue. There is subsequent loaded event for iOS devices. However, what I have observed is that in most cases, there are the expected loaded events, but it’s still missing in some case. This has been discussed in another thread, however Corona has not shown they recognize this new problem.

#19

@joe528: I tried moving the removeSelf to the destroyScene with the same results.

I still have no fix for this on 2013.2100, and I can confirm that subsequent ‘loaded’ events are not always properly dispatched on iOS devices.

#20

@max84

(1) Do you put removeEventListener() in exitScene() ? 

    It’s weird that you are experiencing this crash. My app is a reader app and relies on the webView a lot. It does not crash that way as you described.

(2) I have not reported this bug about the loaded event, because I think this single issue is not going to get webView anywhere. If you also rely on webView a lot for your apps, I hope you can also join the force to make Corona identify webView’s “whole” problem.