Bug 13275 - Safari crashed when trying to login using the windows live contact control
: Safari crashed when trying to login using the windows live contact control
Status: RESOLVED FIXED
Product: WebKit
Classification: Unclassified
Component: Page Loading
: 523.x (Safari 3)
: Macintosh PowerPC Mac OS X 10.4
: P1 Major
Assigned To: Nobody
http://dev.live.com/mashups/trycontac...
: InRadar
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2007-04-03 17:51 PDT by Tom Pennings
Modified: 2007-05-14 05:39 PDT (History)
3 users (show)

See Also:


Attachments
Full crash log (18.69 KB, application/octet-stream)
2007-04-04 17:38 PDT, Tom Pennings
no flags Details
Patch (no layout test) (1.14 KB, patch)
2007-05-13 06:54 PDT, Andrew Wellington
darin: review+
Details | Formatted Diff | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Tom Pennings 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
Comment 1 David Kilzer (:ddkilzer) 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!

Comment 2 David Kilzer (:ddkilzer) 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

Comment 3 David Kilzer (:ddkilzer) 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

Comment 4 David Kilzer (:ddkilzer) 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.

Comment 5 Tom Pennings 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
Comment 6 Darin Adler 2007-04-11 02:10:20 PDT
<rdar://problem/5126391>
Comment 7 Andrew Wellington 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.
Comment 8 Alexey Proskuryakov 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.
Comment 9 Alexey Proskuryakov 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.
Comment 10 Darin Adler 2007-05-13 13:59:42 PDT
Comment on attachment 14535 [details]
Patch (no layout test)

r=me
Comment 11 Anders Carlsson 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.
Comment 12 Andrew Wellington 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.