Bug 14503

Summary: REGRESSION: Navigating away from certain pages with dynamically created iframes triggers an ASSERT in Widget::~Widget
Product: WebKit Reporter: Alan Steremberg <alans>
Component: DOMAssignee: Nobody <webkit-unassigned>
Severity: Critical CC: ap, ddkilzer, dev+webkit, mitz
Priority: P1 Keywords: HasReduction, InRadar, PlatformOnly, Regression
Version: 523.x (Safari 3)   
Hardware: PC   
OS: Windows XP   
URL: http://www.steremberg.com/safari/crashbug.html
Description Flags
Test case from Comment #0
Crashlog none

Description Alan Steremberg 2007-07-02 18:52:59 PDT
executing the following javascript causes safari on Windows and iPhone to be unstable, and usually crash after going to one or two new URLs (ie: www.yahoo.com)

If you click on the steremberg.com url, make sure you wait a second so the javascript body load will fire before going to yahoo. If it doesn't crash, click back or something it almost always crashes for me.

<script >
function addIFrame()
    with (document.getElementsByTagName("body")[0].appendChild(document.createElement("iframe")))
        setAttribute("id", "condscript", 0);
        setAttribute("src", "http://stationdata.wunderground.com/xmlrequest.html",0);

Comment 1 mitz 2007-07-03 04:39:59 PDT
I cannot reproduce on Mac OS X (neither with TOT nor with the beta).
Comment 2 Alan Steremberg 2007-07-03 21:43:29 PDT
Actually, I can't reproduce this on iPhone. I don't have one to test, so I will need to dig and see what is causing iphone to crash on the google map feature on wunderground.com
Comment 3 David Kilzer (:ddkilzer) 2007-07-07 09:39:57 PDT
Created attachment 15433 [details]
Test case from Comment #0
Comment 4 David Kilzer (:ddkilzer) 2007-07-07 09:50:29 PDT
Adding speculative PlatformOnly key since this isn't reproducible on Mac OS X.  Can anyone confirm that this is reproducible on Windows?

Comment 5 Matt Lilek 2007-07-07 11:04:56 PDT
The attached testcase crashes Safari on Windows XP with a local debug build of r24086. This does not crash in Safari 3.0.2 Beta.

*----> Stack Back Trace <----*

*** ERROR: Symbol file could not be found.  Defaulted to export symbols for c:\Program Files\Safari\CFNetwork.dll - 

WARNING: Stack unwind information not available. Following frames may be wrong.

ChildEBP RetAddr  Args to Child              

0012e838 1061e3c4 0012ea3c 0012eb28 6fc057ad WebKit_debug!WebCore__Widget__~Widget+0x58

0012e934 10730ee7 0012eb1c 0012eb28 6fc057ad WebKit_debug!WebCore__ScrollView__~ScrollView+0x84

0012ea3c 10730cab 0012ec28 0012eb28 6fc057ad WebKit_debug!WebCore__FrameView__~FrameView+0x1f7

0012eb1c 105050e5 00000001 0012ec34 cccccccc WebKit_debug!WebCore__FrameView__`scalar deleting destructor'+0x2b

0012eb3c 1063420f 0012ed10 0012ec34 6fc057ad WebKit_debug!WebCore__FrameView__deref+0x55

0012ec28 10624766 00000000 0012ee28 0012ed1c WebKit_debug!WTF__RefPtr<WebCore__FrameView>__operator=+0x4f

0012ed10 1072ac32 00000000 0012ef30 0012ee34 WebKit_debug!WebCore__Frame__setView+0xb6

0012ee28 106f6bf5 034db7c0 0012f028 0012f030 WebKit_debug!WebCore__FrameTree__removeChild+0x42

0012ef30 106f6066 0012f10c 0012f030 6fc057ad WebKit_debug!WebCore__FrameLoader__detachFromParent+0x105

0012f028 106f2fa2 0012f224 0012f118 6fc057ad WebKit_debug!WebCore__FrameLoader__detachChildren+0x66

0012f10c 106f3b9b 031e6028 0012f468 0012f230 WebKit_debug!WebCore__FrameLoader__setDocumentLoader+0xf2

0012f224 106f36f1 00000000 0012f558 0012f91c WebKit_debug!WebCore__FrameLoader__transitionToCommitted+0x18b

0012f468 107092b2 00000000 0012f650 0012f91c WebKit_debug!WebCore__FrameLoader__commitProvisionalLoad+0xb1

0012f558 107094d7 0012f738 0012f91c 6fc057ad WebKit_debug!WebCore__DocumentLoader__commitIfReady+0x62

0012f650 1070968b 02a88fb0 000024db 0012f820 WebKit_debug!WebCore__DocumentLoader__commitLoad+0x37

0012f738 106f1c0a 02a88fb0 000024db 0012f908 WebKit_debug!WebCore__DocumentLoader__receivedData+0x5b

0012f820 1099477e 02a88fb0 000024db 0012fa00 WebKit_debug!WebCore__FrameLoader__receivedData+0x3a

0012f908 10992cda 02a88fb0 000024db 0012f900 WebKit_debug!WebCore__MainResourceLoader__addData+0x4e

0012fa00 109956f0 02a88fb0 000024db 000024db WebKit_debug!WebCore__ResourceLoader__didReceiveData+0x4a

0012fb00 109937c2 02a88fb0 000024db 000024db WebKit_debug!WebCore__MainResourceLoader__didReceiveData+0xf0

0012fbf4 10710860 03492b78 02a88fb0 000024db WebKit_debug!WebCore__ResourceLoader__didReceiveData+0x42

0012fd40 61832fe0 02a67c88 026dcef8 000024db WebKit_debug!WebCore__didReceiveData+0xd0

018861d0 026dcef8 00000000 00000000 00030004 CFNetwork!CFURLConnectionResume+0x3f6

00000003 00000000 00000000 00000000 00000000 0x26dcef8
Comment 6 Matt Lilek 2007-07-07 11:08:24 PDT
(In reply to comment #5)
> The attached testcase crashes Safari on Windows XP with a local debug build of
> r24086. This does not crash in Safari 3.0.2 Beta.

Erm...it's the testcase at the URL that crashes.
Comment 7 Matt Lilek 2007-07-07 11:11:11 PDT
Created attachment 15435 [details]

Here's the full crashlog for posterity.
Comment 8 David Kilzer (:ddkilzer) 2007-07-07 14:07:45 PDT
Comment 9 Geoffrey Garen 2007-09-13 12:37:45 PDT
Steps to reproduce:
1. Load reduction.
2. Load javascript:addIFrame()
3. Load cnn.com

In a debug build, Widget::~Widget() crashes at the line `ASSERT(!parent())'.
Comment 10 Geoffrey Garen 2007-09-13 12:39:58 PDT
WidgetMac.mm does not contain the same assertion. Perhaps it's bogus.
Comment 11 Geoffrey Garen 2007-09-13 13:55:30 PDT
With the ASSERT removed, I hit a NULL-dereference crash beneath ScrollView::geometryChanged, iterating over the ScrollView's children.
Comment 12 Geoffrey Garen 2007-09-13 19:30:51 PDT
The sequence of events is this:
1. <iframe> element creates FrameView A
2. JavaScripts sets <iframe> element's id and src attributes
3. <iframe> element responds to src attribute change by trying to load a URL into FrameView A
4. <iframe> element can't find FrameView A because its id has changed, so it creates FrameView B
5. FrameView A later ASSERTs in its destructor because it hasn't been removed from its parent

My guess is that resolving the frame doubling problem will cause tear-down to proceed normally, fixing the ASSERT.
Comment 13 Geoffrey Garen 2007-09-13 23:36:42 PDT
The fix for bug 15209 fixes this symptom, so I'm going to mark this as a dup.

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