RESOLVED FIXED 22043
ASSERTION FAILED: this == frameLoader()->activeDocumentLoader() (../../WebCore/loader/DocumentLoader.cpp:402 void WebCore::DocumentLoader::updateLoading()) 
https://bugs.webkit.org/show_bug.cgi?id=22043
Summary ASSERTION FAILED: this == frameLoader()->activeDocumentLoader() (../../WebCor...
Holger Freyther
Reported 2008-11-02 14:56:14 PST
The Gtk+ port manages to hit this assert on fast/history/clicked-link-is-visited.html and some more test cases. A backtrace to illustrate what is happening is inside the patch.
Attachments
Do not run into an assert (8.01 KB, patch)
2008-11-02 15:00 PST, Holger Freyther 		darin: review+
DetailsFormatted DiffDiff
View All Add attachment proposed patch, testcase, etc.
Holger Freyther
Comment 1 2008-11-02 15:00:24 PST
Created attachment 24855 [details] Do not run into an assert Proposed patch to not run into the assert. From what I can see is that the CURL backend is not really guilty. FrameLoader is currently using a RefPtr to keep the DocumentLoader alive, so the other ports might have a similar invocation pattern. The question is if the call to dl->setPrimaryLoadComplete(true) can be omitted or not.
David Kilzer (:ddkilzer)
Comment 2 2008-11-29 21:48:11 PST
Comment on attachment 24855 [details] Do not run into an assert > The cruelpit is the following. FrameLoader::finishedLoading is calling I think you want "culprit", not "cruelpit" here. :) Sorry, I don't know enough about the loading machinery to review this patch.
Darin Adler
Comment 3 2008-12-10 14:52:03 PST
Comment on attachment 24855 [details] Do not run into an assert This change seems right. I'm going to say r=me even though this doesn't have a ChangeLog or a test case.
Holger Freyther
Comment 4 2008-12-11 16:37:43 PST
I did land it in r39221. The next step will be to remove some tests from the skipped list.
Note You need to log in before you can comment on or make changes to this bug.