Bug 14503 – REGRESSION: Navigating away from certain pages with dynamically created iframes triggers an ASSERT in Widget::~Widget

• Component: DOM
• Status: RESOLVED DUPLICATE

[Alan Steremberg]

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")))
    {
        style.border='0px';
        style.width='0px';
        style.height='0px';
        setAttribute("id", "condscript", 0);
        setAttribute("src", "http://stationdata.wunderground.com/xmlrequest.html",0);
    }
}

</script>

I cannot reproduce on Mac OS X (neither with TOT nor with the beta).

[Alan Steremberg]

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

[David Kilzer (:ddkilzer)]

Created attachment 15433 [details]
Test case from Comment #0

[David Kilzer (:ddkilzer)]

Adding speculative PlatformOnly key since this isn't reproducible on Mac OS X.  Can anyone confirm that this is reproducible on Windows?

[Matt Lilek]

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

[Matt Lilek]

(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.

[Matt Lilek]

Created attachment 15435 [details]
Crashlog

Here's the full crashlog for posterity.

[David Kilzer (:ddkilzer)]

<rdar://problem/5319623>

[Geoffrey Garen]

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())'.

[Geoffrey Garen]

WidgetMac.mm does not contain the same assertion. Perhaps it's bogus.

[Geoffrey Garen]

With the ASSERT removed, I hit a NULL-dereference crash beneath ScrollView::geometryChanged, iterating over the ScrollView's children.

[Geoffrey Garen]

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.

[Geoffrey Garen]

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 ***