Created attachment 261806 [details]
I am sorry if this is not the right place to post this bug report.
I noticed that not long ago contentsSizeRespectingOverflow was exposed to UIWebView (https://bugs.webkit.org/show_bug.cgi?id=146924). Since then iOS9 has been released which I am assuming has used this newly exposed function, as I am getting crashes with this kind of stack trace:
Exception Type: SIGSEGV
Exception Codes: SEGV_ACCERR at 0x100000057
Thread 0 Crashed:
0 WebCore 0x000000019483bba4 WebCore::FrameView::contentsSizeRespectingOverflow() const + 128
1 WebKitLegacy 0x00000001953ee774 -[WebView(WebPrivate) _contentsSizeRespectingOverflow] + 40
2 UIKit 0x0000000187e2fd00 -[UIWebDocumentView _updateSize] + 496
3 CoreFoundation 0x000000018282e6ac __CFNOTIFICATIONCENTER_IS_CALLING_OUT_TO_AN_OBSERVER__ + 16
4 CoreFoundation 0x000000018282decc _CFXRegistrationPost + 392
5 CoreFoundation 0x000000018282dc4c ___CFXNotificationPost_block_invoke + 56
6 CoreFoundation 0x0000000182893434 -[_CFXNotificationRegistrar find:object:observer:enumerator:] + 1528
7 CoreFoundation 0x000000018276e834 _CFXNotificationPost + 364
8 Foundation 0x00000001836da2fc -[NSNotificationCenter postNotificationName:object:userInfo:] + 64
9 CoreFoundation 0x000000018288ea80 __invoking___ + 140
10 CoreFoundation 0x000000018278c5f4 -[NSInvocation invoke] + 280
11 WebCore 0x0000000194401884 HandleDelegateSource(void*) + 104
12 CoreFoundation 0x00000001828405a4 __CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE0_PERFORM_FUNCTION__ + 20
13 CoreFoundation 0x0000000182840038 __CFRunLoopDoSources0 + 536
14 CoreFoundation 0x000000018283dd38 __CFRunLoopRun + 720
15 CoreFoundation 0x000000018276cdc0 CFRunLoopRunSpecific + 380
16 GraphicsServices 0x000000018d8c0088 GSEventRunModal + 176
17 UIKit 0x0000000187e46f60 UIApplicationMain + 200
18 [OurApp] 0x000000010002813c main (main.m:18)
19 libdyld.dylib 0x0000000197ca68b8 start + 0
As you can see, it seems to be in WebCore.
What the UIWebView was doing at the time was loading a page. It is the first page that that instance has loaded, but it is the second instance of UIWebView that the app has used (the first one is still allocated - the new one has been pushed onto the view stack - sorry if these details are too iOS app specific.
If there are any more details that I can give, please let me know. I have a disassembler (I guess that's what it is) stack trace from replicating this in the xcode debugger, but I'm not sure that is any more useful... I'll attach it anyway.
I have made a minimal app that exhibits the problem. It ONLY does it on one specific web page that loads though. I am trying to work through what is on that page to narrow it down to a minimal page that has the issue, but it is proving difficult. Removing a particular script (re-targeting I think) from the body makes the problem go away, but having only that script does not cause the crash. Having that script with a bit of the page (other scripts, google analytics, etc) the crash happens. It seem like it could be a timing issue or something?
I will provide the app code to reproduce if I can get to a point where it is minimal and does not need me to upload any private information.
Please file this at bugreporter.apple.com, attach your test app to the report, and give the resulting bug number here.
Was a bug filed at Apple? We're facing the same crash and are having a hard time figuring out what happens in the webview.
Possibly fixed in http://trac.webkit.org/changeset/188298.
Bug filed with apple: 22889402
It may well be solved with 188298.
It does not seem to crash if I reuse the same UIWebView instance, only when I create a new instance for each request.
I, being totally unaware of the webkit/ios workflow regarding changeset, have a question. If the changeset will in fact solve the problem, when will it eventually impact iOS?
This was fixed in iOS 9.1 and later.
*** This bug has been marked as a duplicate of bug 147848 ***