WebKit Bugzilla
New
Browse
Log In
×
Sign in with GitHub
or
Remember my login
Create Account
·
Forgot Password
Forgotten password account recovery
RESOLVED FIXED
68291
ASSERTION FAILED: documentLoader in WebKit/Source/WebCore/inspector/InspectorInstrumentation.cpp(597)
https://bugs.webkit.org/show_bug.cgi?id=68291
Summary
ASSERTION FAILED: documentLoader in WebKit/Source/WebCore/inspector/Inspector...
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
Details
Formatted Diff
Diff
Patch
(7.05 KB, patch)
2011-09-22 11:18 PDT
,
Vsevolod Vlasov
tony
: review+
Details
Formatted Diff
Diff
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.
Top of Page
Format For Printing
XML
Clone This Bug