Bug 13275 – Safari crashed when trying to login using the windows live contact control

• Component: Page Loading
• Status: RESOLVED FIXED

[Tom Pennings]

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

[David Kilzer (:ddkilzer)]

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)]

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)]

This Live.com account from Bug 5695 Comment #14 may be used to test with:

User: [e-mail]
Pass: w3bk1t

[David Kilzer (:ddkilzer)]

(In reply to comment #3)
> This Live.com account from Bug 5695 Comment #14 may be used to test with:
> 
> User: [e-mail]
> 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]

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]

<rdar://problem/5126391>

[Andrew Wellington]

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]

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

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 on attachment 14535 [details]
Patch (no layout test)

r=me

[Anders Carlsson]

I would like to see a comment explaining the null check here, and a reference to this bug.

[Andrew Wellington]

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.