RESOLVED FIXED 13275
Safari crashed when trying to login using the windows live contact control
https://bugs.webkit.org/show_bug.cgi?id=13275
Summary Safari crashed when trying to login using the windows live contact control
Tom Pennings
Reported 2007-04-03 17:51:58 PDT
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
Attachments
Full crash log (18.69 KB, application/octet-stream)
2007-04-04 17:38 PDT, Tom Pennings
no flags
Patch (no layout test) (1.14 KB, patch)
2007-05-13 06:54 PDT, Andrew Wellington
darin: review+
David Kilzer (:ddkilzer)
Comment 1 2007-04-04 11:29:52 PDT
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!
David Kilzer (:ddkilzer)
Comment 2 2007-04-04 11:40:00 PDT
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
David Kilzer (:ddkilzer)
Comment 3 2007-04-04 11:44:06 PDT
This Live.com account from Bug 5695 Comment #14 may be used to test with: User: webkit-test@hotmail.com Pass: w3bk1t
David Kilzer (:ddkilzer)
Comment 4 2007-04-04 11:46:48 PDT
(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.
Tom Pennings
Comment 5 2007-04-04 17:38:51 PDT
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
Darin Adler
Comment 6 2007-04-11 02:10:20 PDT
Andrew Wellington
Comment 7 2007-05-13 06:54:46 PDT
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.
Alexey Proskuryakov
Comment 8 2007-05-13 07:05:35 PDT
(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.
Alexey Proskuryakov
Comment 9 2007-05-13 07:07:30 PDT
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.
Darin Adler
Comment 10 2007-05-13 13:59:42 PDT
Comment on attachment 14535 [details] Patch (no layout test) r=me
Anders Carlsson
Comment 11 2007-05-14 02:14:08 PDT
I would like to see a comment explaining the null check here, and a reference to this bug.
Andrew Wellington
Comment 12 2007-05-14 05:39:49 PDT
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.
Note You need to log in before you can comment on or make changes to this bug.