Requirements: 1. Nightly build 2. Windows Live Account 1. Download the nightly build 2. Enter http://dev.live.com/mashups/trycontactscontrol as URL and press enter 3. On the right there is a box with title "Windows Live Contacts Beta" 4. Select Sign In 5. A New window will appear 6. Enter your data and select sign in 7. Window disappears and the box on the right will show "Loading.." 8. Safari will crash
Hi Tom, thanks for the bug report! Could you post a stack trace either as an attachment or as a comment on this bug? Thanks!
This looks like more frame wackiness. Reproducible crashers are P1. Verified with a local debug build of WebKit r20699 with Safari 2.0.4 (419.3) on Mac OS X 10.4.9 (8P135). Console output: Bus error Stack trace: Exception: EXC_BAD_ACCESS (0x0001) Codes: KERN_PROTECTION_FAILURE (0x0002) at 0x00000080 Thread 0 Crashed: 0 com.apple.WebCore 0x01647a78 KJS::Window::frame() const + 20 (kjs_window.h:108) 1 com.apple.WebCore 0x012d0fac KJS::JSAbstractEventListener::handleEvent(WebCore::Event*, bool) + 148 (kjs_events.cpp:81) 2 com.apple.WebCore 0x01206d5c WebCore::XMLHttpRequest::callReadyStateChangeListener() + 388 (xmlhttprequest.cpp:305) 3 com.apple.WebCore 0x012070d4 WebCore::XMLHttpRequest::changeState(WebCore::XMLHttpRequestState) + 68 (xmlhttprequest.cpp:297) 4 com.apple.WebCore 0x01207130 WebCore::XMLHttpRequest::didReceiveData(WebCore::SubresourceLoader*, char const*, int) + 72 (xmlhttprequest.cpp:656) 5 com.apple.WebCore 0x01481038 WebCore::SubresourceLoader::didReceiveData(char const*, int, long long, bool) + 180 (SubresourceLoader.cpp:177) 6 com.apple.WebCore 0x0147f358 WebCore::ResourceLoader::didReceiveData(WebCore::ResourceHandle*, char const*, int, int) + 108 7 com.apple.WebCore 0x014558dc -[WebCoreResourceHandleAsDelegate connection:didReceiveData:lengthReceived:] + 244 (ResourceHandleMac.mm:352) 8 com.apple.Foundation 0x92c13624 -[NSURLConnection(NSURLConnectionInternal) _sendDidReceiveDataCallback] + 564 9 com.apple.Foundation 0x92c11ac4 -[NSURLConnection(NSURLConnectionInternal) _sendCallbacks] + 488 10 com.apple.Foundation 0x92c11860 _sendCallbacks + 156 11 com.apple.CoreFoundation 0x907df4fc __CFRunLoopDoSources0 + 384 12 com.apple.CoreFoundation 0x907dea2c __CFRunLoopRun + 452 13 com.apple.CoreFoundation 0x907de4ac CFRunLoopRunSpecific + 268 14 com.apple.HIToolbox 0x93298b20 RunCurrentEventLoopInMode + 264 15 com.apple.HIToolbox 0x9329812c ReceiveNextEventCommon + 244 16 com.apple.HIToolbox 0x93298020 BlockUntilNextEventMatchingListInMode + 96 17 com.apple.AppKit 0x9379eae4 _DPSNextEvent + 384 18 com.apple.AppKit 0x9379e7a8 -[NSApplication nextEventMatchingMask:untilDate:inMode:dequeue:] + 116 19 com.apple.Safari 0x00006740 0x1000 + 22336 20 com.apple.AppKit 0x9379acec -[NSApplication run] + 472 21 com.apple.AppKit 0x9388b87c NSApplicationMain + 452 22 com.apple.Safari 0x0005c77c 0x1000 + 374652 23 com.apple.Safari 0x0005c624 0x1000 + 374308
This Live.com account from Bug 5695 Comment #14 may be used to test with: User: webkit-test@hotmail.com Pass: w3bk1t
(In reply to comment #3) > This Live.com account from Bug 5695 Comment #14 may be used to test with: > > User: webkit-test@hotmail.com > Pass: w3bk1t This used to go to mail.live.com when checking mail, but the account was reset, so it's back to Hotmail. It still crashes when logging in while testing this bug.
Created attachment 13954 [details] Full crash log This is the full crash log as reported by the Console.app. Thanks for being on top of this David
<rdar://problem/5126391>
Created attachment 14535 [details] Patch (no layout test) This fixes the problem as the XMLHttpRequest returns after the window has been destroyed, causing a null dereference. I'm not sure how (or if it's possible) to make a layout test for this: we need to have an xmlhttprequest return data after a window has already been destroyed. Pointers as to how (if possible) to do a layout test would be great.
(In reply to comment #7) > I'm not sure how (or if it's possible) to make a layout test for this: we need > to have an xmlhttprequest return data after a window has already been > destroyed. If I understood the problem correctly, you can use something similar to http/tests/xmlhttprequest/resources/endlessxml.php.
I think the real fix would be to make XHR hold a reference to window, as per the draft spec. But maybe plugging the crasher like this is OK for now.
Comment on attachment 14535 [details] Patch (no layout test) r=me
I would like to see a comment explaining the null check here, and a reference to this bug.
Committed with a comment above the null check as suggested by Anders. I wasn't able to create a LayoutTest to reliably reproduce the issue however, so no layout test is included.