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
: WebKit
Page Loading
: 523.x (Safari 3)
: Macintosh PowerPC Mac OS X 10.4
: P1 Major
Assigned To:
: http://dev.live.com/mashups/trycontac...
: InRadar
:
:
  Show dependency treegraph
 
Reported: 2007-04-03 17:51 PST by
Modified: 2007-05-14 05:39 PST (History)


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


Note

You need to log in before you can comment on or make changes to this bug.


Description From 2007-04-03 17:51:58 PST
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 From 2007-04-04 11:29:52 PST -------
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 From 2007-04-04 11:40:00 PST -------
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 From 2007-04-04 11:44:06 PST -------
This Live.com account from Bug 5695 Comment #14 may be used to test with:

User: webkit-test@hotmail.com
Pass: w3bk1t
------- Comment #4 From 2007-04-04 11:46:48 PST -------
(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 From 2007-04-04 17:38:51 PST -------
Created an attachment (id=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 From 2007-04-11 02:10:20 PST -------
<rdar://problem/5126391>
------- Comment #7 From 2007-05-13 06:54:46 PST -------
Created an attachment (id=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 From 2007-05-13 07:05:35 PST -------
(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 From 2007-05-13 07:07:30 PST -------
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 From 2007-05-13 13:59:42 PST -------
(From update of attachment 14535 [details])
r=me
------- Comment #11 From 2007-05-14 02:14:08 PST -------
I would like to see a comment explaining the null check here, and a reference to this bug.
------- Comment #12 From 2007-05-14 05:39:49 PST -------
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.