Bug 149495 - REGRESSION (iOS 9): SIGSEGV in contentsSizeRespectingOverflow (UIWebView)
Summary: REGRESSION (iOS 9): SIGSEGV in contentsSizeRespectingOverflow (UIWebView)
Status: RESOLVED DUPLICATE of bug 147848
Alias: None
Product: WebKit
Classification: Unclassified
Component: WebCore Misc. (show other bugs)
Version: WebKit Nightly Build
Hardware: iPhone / iPad iOS 9.0
: P2 Normal
Assignee: Nobody
URL:
Keywords: InRadar
Depends on:
Blocks:
 
Reported: 2015-09-23 01:34 PDT by David
Modified: 2016-06-13 18:10 PDT (History)
3 users (show)

See Also:


Attachments
assembly stacktrace (4.54 KB, text/plain)
2015-09-23 01:34 PDT, David
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description David 2015-09-23 01:34:22 PDT
Created attachment 261806 [details]
assembly stacktrace

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.
Comment 1 Simon Fraser (smfr) 2015-09-27 21:55:33 PDT
Please file this at bugreporter.apple.com, attach your test app to the report, and give the resulting bug number here.
Comment 2 Jesper Nielsen 2015-09-28 04:54:26 PDT
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.
Comment 3 Simon Fraser (smfr) 2015-09-28 13:50:37 PDT
Possibly fixed in http://trac.webkit.org/changeset/188298.
Comment 4 David 2015-09-28 17:01:17 PDT
Bug filed with apple: 22889402
Comment 5 David 2015-09-28 17:04:41 PDT
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.
Comment 6 Jesper Nielsen 2015-09-29 03:57:04 PDT
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?
Comment 7 David Kilzer (:ddkilzer) 2015-10-09 08:59:03 PDT
<rdar://problem/22889402>
Comment 8 David Kilzer (:ddkilzer) 2016-06-13 18:10:26 PDT
This was fixed in iOS 9.1 and later.

*** This bug has been marked as a duplicate of bug 147848 ***