Bug 68291

Summary: ASSERTION FAILED: documentLoader in WebKit/Source/WebCore/inspector/InspectorInstrumentation.cpp(597)
Product: WebKit Reporter: Tony Chang <tony>
Component: Web Inspector (Deprecated)Assignee: Vsevolod Vlasov <vsevik>
Status: RESOLVED FIXED    
Severity: Normal CC: ap, loislo, pfeldman, vsevik, yurys
Priority: P2    
Version: 528+ (Nightly build)   
Hardware: Unspecified   
OS: Unspecified   
Attachments:
Description Flags
test server
none
Patch
none
Patch tony: review+

Tony Chang
Reported 2011-09-16 16:36:36 PDT
When loading a multipart page, I hit this assert in Chrome. It seems to work fine when using test_shell. ASSERTION FAILED: documentLoader ../../third_party/WebKit/Source/WebCore/inspector/InspectorInstrumentation.cpp(597) : static void WebCore::InspectorInstrumentation::loadEventFiredImpl(WebCore::InstrumentingAgents*, WebCore::Frame*, const WebCore::KURL&) Specifically, if I run "out/Debug/chrome http://localhost:8099/multipart", I hit the assert. I've attached the python webserver (just run python test-server-simple.py to launch).
Attachments
test server (909 bytes, text/plain)
2011-09-16 16:37 PDT, Tony Chang 		no flags
Details
Patch (2.47 KB, patch)
2011-09-22 06:15 PDT, Vsevolod Vlasov 		no flags
DetailsFormatted DiffDiff
Patch (7.05 KB, patch)
2011-09-22 11:18 PDT, Vsevolod Vlasov 		tony: review+
DetailsFormatted DiffDiff
Show Obsolete (1) View All Add attachment proposed patch, testcase, etc.
Tony Chang
Comment 1 2011-09-16 16:37:26 PDT
Created attachment 107745 [details] test server
Vsevolod Vlasov
Comment 2 2011-09-21 10:55:07 PDT
Probably related: http://code.google.com/p/chromium/issues/detail?id=94392
Vsevolod Vlasov
Comment 3 2011-09-22 06:15:52 PDT
Created attachment 108323 [details] Patch
Vsevolod Vlasov
Comment 4 2011-09-22 06:29:14 PDT
I was not able to reproduce this bug, but this piece of code could be simplified to ensure this does not happens anymore.
WebKit Review Bot
Comment 5 2011-09-22 10:27:48 PDT
Comment on attachment 108323 [details] Patch Attachment 108323 [details] did not pass mac-ews (mac): Output: http://queues.webkit.org/results/9794302
Vsevolod Vlasov
Comment 6 2011-09-22 11:18:56 PDT
Created attachment 108368 [details] Patch
Tony Chang
Comment 7 2011-09-22 16:13:42 PDT
Comment on attachment 108368 [details] Patch Seems fine. Might want to have someone more familiar with Inspector code also take a look.
Yury Semikhatsky
Comment 8 2011-09-22 23:47:48 PDT
(In reply to comment #7) > (From update of attachment 108368 [details]) > Seems fine. Might want to have someone more familiar with Inspector code also take a look. Tony, are you sure url != documentLoader->requestURL() check was redundant there?
Yury Semikhatsky
Comment 9 2011-09-23 00:21:14 PDT
Comment on attachment 108368 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=108368&action=review > Source/WebCore/inspector/InspectorInstrumentation.cpp:-602 > - if (frame->page()->mainFrame() != frame || url != documentLoader->requestURL()) Do we receive load event notifications only for the frame main resource? If not, the check should be preserved.
Vsevolod Vlasov
Comment 10 2011-09-23 03:20:21 PDT
(In reply to comment #9) > (From update of attachment 108368 [details]) > View in context: https://bugs.webkit.org/attachment.cgi?id=108368&action=review > > > Source/WebCore/inspector/InspectorInstrumentation.cpp:-602 > > - if (frame->page()->mainFrame() != frame || url != documentLoader->requestURL()) > > Do we receive load event notifications only for the frame main resource? If not, the check should be preserved. loadEventFired() and domContentLoadedEventFired() are called only from DOMWindow and Document always passing frame main resource url.
Vsevolod Vlasov
Comment 11 2011-09-23 03:46:29 PDT
Committed r95790: <http://trac.webkit.org/changeset/95790>
Note You need to log in before you can comment on or make changes to this bug.