Bug 37322 – [Qt] tst_QWebHistory::serialize_2() fails

• Component: Tools / Tests
• Status: CLOSED FIXED

[Simon Hausmann]

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)]

[Jędrzej Nowacki]

I can reproduce it on debian(32)

[Jędrzej Nowacki]

The crash is caused by https://bugs.webkit.org/show_bug.cgi?id=33224

[Jędrzej Nowacki]

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.

[Jędrzej Nowacki]

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.

[Jędrzej Nowacki]

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.

[Jędrzej Nowacki]

(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.

[Diego Gonzalez]

I did no get this test failing anymore. Does anyone is getting this test still failing?

[Jędrzej Nowacki]

(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).

[Diego Gonzalez]

(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 :)

[Jesus Sanchez-Palencia]

*** Bug 38679 has been marked as a duplicate of this bug. ***

[Simon Hausmann]

Committed r59660: <http://trac.webkit.org/changeset/59660>

[Simon Hausmann]

Revision r59660 cherry-picked into qtwebkit-2.0 with commit 71e6346a3e2bf9d137d03be4d6dcff79ea0c8358

[WebKit Review Bot]

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