Summary: | REGRESSION: Navigating away from certain pages with dynamically created iframes triggers an ASSERT in Widget::~Widget | ||||||||
---|---|---|---|---|---|---|---|---|---|
Product: | WebKit | Reporter: | Alan Steremberg <alans> | ||||||
Component: | DOM | Assignee: | Nobody <webkit-unassigned> | ||||||
Status: | RESOLVED DUPLICATE | ||||||||
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 | ||||||||
Attachments: |
|
Description
Alan Steremberg
2007-07-02 18:52:59 PDT
I cannot reproduce on Mac OS X (neither with TOT nor with the beta). 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 Created attachment 15433 [details] Test case from Comment #0 Adding speculative PlatformOnly key since this isn't reproducible on Mac OS X. Can anyone confirm that this is reproducible on Windows? 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 (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. Created attachment 15435 [details]
Crashlog
Here's the full crashlog for posterity.
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())'. WidgetMac.mm does not contain the same assertion. Perhaps it's bogus. With the ASSERT removed, I hit a NULL-dereference crash beneath ScrollView::geometryChanged, iterating over the ScrollView's children. 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. |