Summary: | Safari crashes during load of LexisNexis search results | ||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
Product: | WebKit | Reporter: | Sam Stigler <sstigler1985> | ||||||||||||||
Component: | Page Loading | Assignee: | Darin Adler <darin> | ||||||||||||||
Status: | RESOLVED FIXED | ||||||||||||||||
Severity: | Major | CC: | ddkilzer, dev+webkit, mark, mitz | ||||||||||||||
Priority: | P1 | Keywords: | InRadar | ||||||||||||||
Version: | 523.x (Safari 3) | ||||||||||||||||
Hardware: | Mac (Intel) | ||||||||||||||||
OS: | OS X 10.5 | ||||||||||||||||
URL: | http://www.lexisnexis.com:80/us/lnacademic/search/loadForm.do?formID=AC00NBGenSrch&random=0.230971188932794 | ||||||||||||||||
Attachments: |
|
Description
Sam Stigler
2007-11-22 21:01:21 PST
Sam, does this happen with a WebKit nightly build? <http://nightly.webkit.org/> Looks like a multi-part request issue. (May be hard to reproduce without access to the actual web site.) We probably need a packet trace if we can't get access to the site (e.g., using tcpdump). (In reply to comment #1) > Looks like a multi-part request issue. (May be hard to reproduce without > access to the actual web site.) We probably need a packet trace if we can't > get access to the site (e.g., using tcpdump). Sam, could you capture a packet trace when Safari crashes? Basically, run this command from a Terminal window BEFORE Step 6 in Comment #0 (assuming your ethernet port is en1; if you're using a wireless connection it may be en1; run the "ifconfig -a" command and pick the interface that has a valid IP address with it): sudo tcpdump -s 0 -w packets.tcpdump -i en0 Then click the "Search" button as in Step 6. When Safari has crashed, hit Ctrl-C to stop the command, then attach packets.tcpdump to this bug. Please note that this command will capture ALL network traffic, so please don't log into any other sites while you're running the command. If you'd rather not post the packet dump to the bug, please send me private email. Yes. I was just able to reproduce this with the November 29, 2007 nightly build (28129). (In reply to comment #1) > Sam, does this happen with a WebKit nightly build? > <http://nightly.webkit.org/> > > Looks like a multi-part request issue. (May be hard to reproduce without > access to the actual web site.) We probably need a packet trace if we can't > get access to the site (e.g., using tcpdump). > Created attachment 17588 [details]
Packet trace from crash on build 28129 (29 Nov. 2007)
While I was able to reproduce this on build 28129, the behavior of the bug was slightly different: This time the page loaded, for the most part, but seemed to be waiting for one more thing. Then after a few seconds the crash occurred. I'm pasting in an updated stack trace for Thread 0 below; please note this most recent crash occurred in a different method: Exception Type: EXC_BAD_ACCESS (SIGBUS) Exception Codes: KERN_PROTECTION_FAILURE at 0x0000000000000000 Crashed Thread: 0 Thread 0 Crashed: 0 ??? 0000000000 0 + 0 1 com.apple.WebCore 0x00c7c2e4 WebCore::FrameLoader::endIfNotLoadingMainResource() + 116 2 com.apple.WebCore 0x00c13833 WebCore::Document::close() + 35 3 com.apple.WebCore 0x00d69606 WebCore::JSHTMLDocumentPrototypeFunctionClose::callAsFunction(KJS::ExecState*, KJS::JSObject*, KJS::List const&) + 70 4 com.apple.JavaScriptCore 0x00340ac0 KJS::FunctionCallDotNode::evaluate(KJS::ExecState*) + 816 5 com.apple.JavaScriptCore 0x0032b5ed KJS::ExprStatementNode::execute(KJS::ExecState*) + 109 6 com.apple.JavaScriptCore 0x002ec28d KJS::BlockNode::execute(KJS::ExecState*) + 61 7 com.apple.JavaScriptCore 0x0032b71b KJS::IfNode::execute(KJS::ExecState*) + 203 8 com.apple.JavaScriptCore 0x003621c3 KJS::FunctionBodyNode::execute(KJS::ExecState*) + 467 9 com.apple.JavaScriptCore 0x002ea13c KJS::FunctionImp::execute(KJS::ExecState*) + 28 10 com.apple.JavaScriptCore 0x0035f953 KJS::FunctionImp::callAsFunction(KJS::ExecState*, KJS::JSObject*, KJS::List const&) + 387 11 com.apple.JavaScriptCore 0x003432ed KJS::FunctionCallResolveNode::evaluate(KJS::ExecState*) + 909 12 com.apple.JavaScriptCore 0x0032b5ed KJS::ExprStatementNode::execute(KJS::ExecState*) + 109 13 com.apple.JavaScriptCore 0x003621c3 KJS::FunctionBodyNode::execute(KJS::ExecState*) + 467 14 com.apple.JavaScriptCore 0x002ea13c KJS::FunctionImp::execute(KJS::ExecState*) + 28 15 com.apple.JavaScriptCore 0x0035f953 KJS::FunctionImp::callAsFunction(KJS::ExecState*, KJS::JSObject*, KJS::List const&) + 387 16 com.apple.JavaScriptCore 0x00315c17 KJS::JSObject::call(KJS::ExecState*, KJS::JSObject*, KJS::List const&) + 135 17 com.apple.WebCore 0x010b1c69 WebCore::JSAbstractEventListener::handleEvent(WebCore::Event*, bool) + 1433 18 com.apple.WebCore 0x00c43786 WebCore::EventTargetNode::handleLocalEvents(WebCore::Event*, bool) + 182 19 com.apple.WebCore 0x00c440fd WebCore::EventTargetNode::dispatchGenericEvent(WTF::PassRefPtr<WebCore::Event>, int&, bool) + 1053 20 com.apple.WebCore 0x00c4454e WebCore::EventTargetNode::dispatchWindowEvent(WebCore::AtomicString const&, bool, bool) + 478 21 com.apple.WebCore 0x00c13599 WebCore::Document::implicitClose() + 281 22 com.apple.WebCore 0x00c69f44 WebCore::FrameLoader::checkCallImplicitClose() + 308 23 com.apple.WebCore 0x00c7928b WebCore::FrameLoader::checkCompleted() + 187 24 com.apple.WebCore 0x010c4967 WebCore::Loader::didFinishLoading(WebCore::SubresourceLoader*) + 327 25 com.apple.WebCore 0x0104b111 WebCore::SubresourceLoader::didFinishLoading() + 49 26 com.apple.WebCore 0x00f13418 -[WebCoreResourceHandleAsDelegate connectionDidFinishLoading:] + 72 27 com.apple.Foundation 0x94d21357 -[NSURLConnection(NSURLConnectionReallyInternal) sendDidFinishLoading] + 87 28 com.apple.Foundation 0x94d212e4 _NSURLConnectionDidFinishLoading + 68 29 com.apple.CFNetwork 0x91e22adf sendDidFinishLoadingCallback + 148 30 com.apple.CFNetwork 0x91e1f9d2 _CFURLConnectionSendCallbacks + 1908 31 com.apple.CFNetwork 0x91e1f1e3 muxerSourcePerform + 283 32 com.apple.CoreFoundation 0x917ee64e CFRunLoopRunSpecific + 3166 33 com.apple.CoreFoundation 0x917eed38 CFRunLoopRunInMode + 88 34 com.apple.HIToolbox 0x91a7c8a4 RunCurrentEventLoopInMode + 283 35 com.apple.HIToolbox 0x91a7c6bd ReceiveNextEventCommon + 374 36 com.apple.HIToolbox 0x91a7c531 BlockUntilNextEventMatchingListInMode + 106 37 com.apple.AppKit 0x93d09d5b _DPSNextEvent + 657 38 com.apple.AppKit 0x93d096a0 -[NSApplication nextEventMatchingMask:untilDate:inMode:dequeue:] + 128 39 com.apple.Safari 0x00009d4e 0x1000 + 36174 40 com.apple.AppKit 0x93d026d1 -[NSApplication run] + 795 41 com.apple.AppKit 0x93ccf9ba NSApplicationMain + 574 42 com.apple.Safari 0x00002876 0x1000 + 6262 (In reply to comment #4) > Yes. I was just able to reproduce this with the November 29, 2007 nightly > build (28129). > > (In reply to comment #1) > > Sam, does this happen with a WebKit nightly build? > > <http://nightly.webkit.org/> > > > > Looks like a multi-part request issue. (May be hard to reproduce without > > access to the actual web site.) We probably need a packet trace if we can't > > get access to the site (e.g., using tcpdump). > > > My school seems to use this service - I'll find out tomorrow how I can actually log into the thing and see if I can get some more info on this bug. (In reply to comment #7) > My school seems to use this service - I'll find out tomorrow how I can actually > log into the thing and see if I can get some more info on this bug. Cool. I'm looking at the packet trace, but the responses are all chunked/gzipped, and Wireshark won't unchunk them for me. Currently I'm writing a Perl script to read them after saving the "Follow streams" output to files. *** Bug 15170 has been marked as a duplicate of this bug. *** See also Bug 14568. I think there's enough evidence to confirm this issue. I think I found the remaining/other problem. This second crash is not in isLoadingMultipartContent, but it happens with the same test cases. The problem in this case is that the image document doesn't retain its image element, so we get a bad pointer for cachedImage; this is very easy to fix. I can reproduce the crash like this: 1. Visit http://java3d.org/jmenu.html 2. View Moving Images > Car. Wait for the car to spin around at least once. 3. Visit Java 3D Programs > Stereoscopic Cube. Safari crashes before drawing the cube. Created attachment 17625 [details]
patch
Comment on attachment 17625 [details]
patch
+ Steps to reproduce:
Does that need to be in the change log? Can it be turned into a manual test?
r=me
I am worried that this might cause a storage leak. Thinking further about it. (In reply to comment #15) > Can it be turned into a manual test? I don't think it can be turned into a manual test without the HTTP server, since it requires a multipart-mixed-replace image, which you can't do with a file URLs. Created attachment 17626 [details]
Reduction (will crash), can be turned into regression test
The crash scenario is very simple and does not require an http-served (or multipart) image.
(In reply to comment #18) > The crash scenario is very simple and does not require an http-served (or > multipart) image. ...although you need to save the test case to disk and open it from there (probably due to the timing of the load event). Created attachment 17627 [details]
better patch, without so much leaking ;-)
Created attachment 17629 [details]
better patch, also handles case where node is moved out of the document
Created attachment 17630 [details]
patch, compiles now (oops)
Comment on attachment 17630 [details]
patch, compiles now (oops)
r=me
Committed revision 28304. You guys rock! I've confirmed the fix with the original test case on build 28383 (4 December 2007). Thanks! |