Assertion failure in FrameLoadDelegate::locationChangeDone when running http/tests/navigation/back-twice-without-commit.html

• Component: Tools / Tests
• Status: RESOLVED FIXED

To reproduce:

1. run-webkit-tests --debug http/tests/navigation/back-twice-without-commit.html

You'll hit an assertion failure in FrameLoadDelegate::locationChangeDone:

    ASSERT(!g_delegateWaitingOnTimer);

Here's the backtrace:


0012eaf8 0043a8bd 00000000 045b83d8 0012eb3c DumpRenderTree!FrameLoadDelegate::locationChangeDone+0x8e [c:\cygwin\home\buildbot\slave\win-debug\build\tools\dumprendertree\win\frameloaddelegate.cpp @ 229]
0012eb28 01f8a0d1 045b8ea8 045bd630 045b83d8 DumpRenderTree!FrameLoadDelegate::didFinishLoadForFrame+0x9d [c:\cygwin\home\buildbot\slave\win-debug\build\tools\dumprendertree\win\frameloaddelegate.cpp @ 246]
0012eb58 012876be 0012ec48 0012ec50 cccccccc WebKit!WebFrameLoaderClient::dispatchDidFinishLoad+0x81 [c:\cygwin\home\buildbot\slave\win-debug\build\source\webkit\win\webcoresupport\webframeloaderclient.cpp @ 410]
0012ebe4 01287d1b 0012ee74 00000000 00000000 WebKit!WebCore::FrameLoader::checkLoadCompleteForThisFrame+0x49e [c:\cygwin\home\buildbot\slave\win-debug\build\source\webcore\loader\frameloader.cpp @ 2431]
0012ec48 01287e30 0012ec64 045ad3f8 045d1698 WebKit!WebCore::FrameLoader::recursiveCheckLoadComplete+0xdb [c:\cygwin\home\buildbot\slave\win-debug\build\source\webcore\loader\frameloader.cpp @ 2543]
0012ec5c 01286a47 0012ecc4 cccccccc 0c08a4f0 WebKit!WebCore::FrameLoader::checkLoadComplete+0xb0 [c:\cygwin\home\buildbot\slave\win-debug\build\source\webcore\loader\frameloader.cpp @ 2556]
0012ec84 01c4bcd6 0012ecc4 97ed9f42 41d3599c WebKit!WebCore::FrameLoader::finishedLoading+0xd7 [c:\cygwin\home\buildbot\slave\win-debug\build\source\webcore\loader\frameloader.cpp @ 2198]
0012ecb4 01929b97 00000000 00000000 0012ece0 WebKit!WebCore::MainResourceLoader::didFinishLoading+0xe6 [c:\cygwin\home\buildbot\slave\win-debug\build\source\webcore\loader\mainresourceloader.cpp @ 465]
0012eccc 018c5d91 0c072830 00000000 00000000 WebKit!WebCore::ResourceLoader::didFinishLoading+0x27 [c:\cygwin\home\buildbot\slave\win-debug\build\source\webcore\loader\resourceloader.cpp @ 436]
0012ecf0 007dbfd4 0c068b00 0c072830 0012ee54 WebKit!WebCore::didFinishLoading+0xa1 [c:\cygwin\home\buildbot\slave\win-debug\build\source\webcore\platform\network\cf\resourcehandlecfnet.cpp @ 241]
0012ed28 007dc337 0012ed44 a6cf3be6 0012ef90 CFNetwork!URLConnectionClient::_clientDidFinishLoading+0xb1
0012ee2c 007dcf0b 0012ee5c 00000003 0012ef64 CFNetwork!URLConnectionClient::ClientConnectionEventQueue::processAllEventsAndConsumePayload+0xa6
0012ee3c 007dc5bd a6cf3af6 0012f088 0012f034 CFNetwork!XConnectionEventQueue<enum XLoaderEvent,XLoaderEventParams>::processAllEvents+0x14
0012ef3c 007dcf0b 0012ef6c 00000003 0012f074 CFNetwork!URLConnectionClient::ClientConnectionEventQueue::processAllEventsAndConsumePayload+0x32c
0012ef4c 007dc5bd a6cf2586 0012f198 0012f144 CFNetwork!XConnectionEventQueue<enum XLoaderEvent,XLoaderEventParams>::processAllEvents+0x14
0012f04c 007dcf0b 0012f07c 00000001 0012f184 CFNetwork!URLConnectionClient::ClientConnectionEventQueue::processAllEventsAndConsumePayload+0x32c
0012f05c 007dc5bd a6cf2496 0012f2a8 0012f254 CFNetwork!XConnectionEventQueue<enum XLoaderEvent,XLoaderEventParams>::processAllEvents+0x14
0012f15c 007dcf0b 0012f18c 00000001 0012f294 CFNetwork!URLConnectionClient::ClientConnectionEventQueue::processAllEventsAndConsumePayload+0x32c
0012f16c 007dc5bd a6cf27a6 09c43c04 0012f364 CFNetwork!XConnectionEventQueue<enum XLoaderEvent,XLoaderEventParams>::processAllEvents+0x14
0012f26c 007dcf0b 0012f29c 00000001 09c43bf0 CFNetwork!URLConnectionClient::ClientConnectionEventQueue::processAllEventsAndConsumePayload+0x32c
0012f27c 007dc5bd a6cf26b6 09c43bf0 09c43cc0 CFNetwork!XConnectionEventQueue<enum XLoaderEvent,XLoaderEventParams>::processAllEvents+0x14
0012f37c 007dcf0b 09c43bf8 00000001 0bb16618 CFNetwork!URLConnectionClient::ClientConnectionEventQueue::processAllEventsAndConsumePayload+0x32c
0012f38c 007dc6cd 0012f414 0c068b00 0012f3ac CFNetwork!XConnectionEventQueue<enum XLoaderEvent,XLoaderEventParams>::processAllEvents+0x14
0012f3a0 007da495 007da45d 0012f3d8 7e418734 CFNetwork!URLConnectionClient::processEvents+0x44
0012f3ac 7e418734 075f0196 000004cf 0c068b00 CFNetwork!MirroredSet::contains+0x5b
0012f3d8 7e418816 007da45d 075f0196 000004cf USER32!InternalCallWinProc+0x28
0012f440 7e4189cd 00000000 007da45d 075f0196 USER32!UserCallWinProcCheckWow+0x150
0012f4a0 7e418a10 0012f554 00000000 0012f624 USER32!DispatchMessageWorker+0x306
0012f4b0 00457335 0012f554 0012ff7c 0012f630 USER32!DispatchMessageW+0xf
0012f624 0045611e 0012f69c 0048ca40 00000001 DumpRenderTree!runTest+0x775 [c:\cygwin\home\buildbot\slave\win-debug\build\tools\dumprendertree\win\dumprendertree.cpp @ 1002]
0012ff7c 0046510f 00000002 045a9f70 04442cf8 DumpRenderTree!main+0x8ce [c:\cygwin\home\buildbot\slave\win-debug\build\tools\dumprendertree\win\dumprendertree.cpp @ 1379]
0012ffc0 7c817077 008420a0 0082b620 7ffde000 DumpRenderTree!__tmainCRTStartup+0x10f [f:\dd\vctools\crt_bld\self_x86\crt\src\crtexe.c @ 597]
0012fff0 00000000 004652b0 00000000 78746341 kernel32!BaseProcessStart+0x23

Looks like Mac has no such assertion. Removing the assertion causes the test to pass. But I think we can also make the code handle the case of multiple timers for multiple delegates correctly.

Created an attachment (id=83659) [details]
Change FrameLoadDelegate to support any number of concurrent timers

(From update of attachment 83659 [details])
View in context: https://bugs.webkit.org/attachment.cgi?id=83659&action=review

> Tools/DumpRenderTree/win/FrameLoadDelegate.cpp:220
> +    COMPtr<FrameLoadDelegate> d = timerMap().take(id);

Are timer IDs guaranteed to not be 0 or -1?

(From update of attachment 83659 [details])
View in context: https://bugs.webkit.org/attachment.cgi?id=83659&action=review

>> Tools/DumpRenderTree/win/FrameLoadDelegate.cpp:220
>> +    COMPtr<FrameLoadDelegate> d = timerMap().take(id);
> 
> Are timer IDs guaranteed to not be 0 or -1?

Good question! They are guaranteed not to be 0. But I think -1 is a valid timer ID. I guess we need a slightly different solution.

I should note that I tried adding a similar assertion to DRT on Mac, and it fired for this test. So we're not seeing some Mac/Windows behavior difference here.

Created an attachment (id=83664) [details]
Change FrameLoadDelegate to support any number of delegates with delayed work to process

Committed r79573: <http://trac.webkit.org/changeset/79573>