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).
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.
<rdar://problem/5319623>
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.
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 ***