On Linux/X11: ASSERTION FAILED: item->documentSequenceNumber() == history()->currentItem()->documentSequenceNumber() (../../../WebCore/loader/FrameLoader.cpp:3771 void WebCore::FrameLoader::navigateWithinDocument(WebCore::HistoryItem*)) QFATAL : tst_QWebHistory::serialize_2() Received signal 11 FAIL! : tst_QWebHistory::serialize_2() Received a fatal error. Loc: [Unknown file(0)]
I can reproduce it on debian(32)
The crash is caused by https://bugs.webkit.org/show_bug.cgi?id=33224
Created attachment 52958 [details] solution The diff solve the problem but is a bit strange that we have to set nullitem document sequence number. I'm posting the diff here as a backup, I will investigate.
Created attachment 53708 [details] Fix v1 The solution shoiuld work, I want to do some manual testing before r? flag, but for now it pass all autotests.
Created attachment 53740 [details] Fix v2 Ok, one line solution. Fixes symptoms. After the patch the serialization behave in the same manner as before 33224 bug. Autotests pass. I tried manual testing and it seems to work well.
(In reply to comment #5) > Created an attachment (id=53740) [details] > Fix v2 > > Ok, one line solution. Fixes symptoms. After the patch the serialization behave > in the same manner as before 33224 bug. > > Autotests pass. I tried manual testing and it seems to work well. Patch assumes that if a HistoryItems are in the same group, we can separate them without any consequences. If the assumption is bad then we have to bump streaming protocol version and save on each serialization document sequence number.
I did no get this test failing anymore. Does anyone is getting this test still failing?
(In reply to comment #7) > I did no get this test failing anymore. Does anyone is getting this test still > failing? Hi, yes problem is still valid. It is an assert so it is visible only in debug, do you use debug build? If you use debug build then provide us more information about your platform. Thank you :-) The bug was reproduced with trunk on Linux(Debian - testing 32).
(In reply to comment #8) > (In reply to comment #7) > > I did no get this test failing anymore. Does anyone is getting this test still > > failing? > Hi, yes problem is still valid. It is an assert so it is visible only in debug, > do you use debug build? If you use debug build then provide us more information > about your platform. Thank you :-) > > The bug was reproduced with trunk on Linux(Debian - testing 32). Yes sure, We did not test in debug mode. Got the fail now :)
*** Bug 38679 has been marked as a duplicate of this bug. ***
Committed r59660: <http://trac.webkit.org/changeset/59660>
Revision r59660 cherry-picked into qtwebkit-2.0 with commit 71e6346a3e2bf9d137d03be4d6dcff79ea0c8358
http://trac.webkit.org/changeset/59660 might have broken Chromium Win Release The following changes are on the blame list: http://trac.webkit.org/changeset/59659 http://trac.webkit.org/changeset/59660