Bug 70844 – Crash in WebKit::WebPage::goToBackForwardItem(unsigned long long, WebKit::SandboxExtension::Handle const&) due to assert failure

• Status: CLOSED
• Resolution: DUPLICATE
• Component: Page Loading

[Dimitris Apostolou]

Created attachment 112389 [details]
Crash log.

r98372

Reproducibility: always

Steps:
1. Paste the actual stack trace of this bug into the "Additional Comments" field...
2. Edit -> Undo Typing (or press Cmd+Z)

What happened:
2. Assert failure and crash.

ASSERTION FAILED: item
/Users/rex/WebKit/Source/WebKit2/WebProcess/WebPage/WebPage.cpp(650) : void WebKit::WebPage::goToBackForwardItem(uint64_t, const SandboxExtension::Handle &)
1   0x102f7c9d8 WebKit::WebPage::goToBackForwardItem(unsigned long long, WebKit::SandboxExtension::Handle const&)
2   0x10308d0b8 void CoreIPC::callMemberFunction<WebKit::WebPage, void (WebKit::WebPage::*)(unsigned long long, WebKit::SandboxExtension::Handle const&), unsigned long long, WebKit::SandboxExtension::Handle>(CoreIPC::Arguments2<unsigned long long, WebKit::SandboxExtension::Handle> const&, WebKit::WebPage*, void (WebKit::WebPage::*)(unsigned long long, WebKit::SandboxExtension::Handle const&))
3   0x103082c3a void CoreIPC::handleMessage<Messages::WebPage::GoToBackForwardItem, WebKit::WebPage, void (WebKit::WebPage::*)(unsigned long long, WebKit::SandboxExtension::Handle const&)>(CoreIPC::ArgumentDecoder*, WebKit::WebPage*, void (WebKit::WebPage::*)(unsigned long long, WebKit::SandboxExtension::Handle const&))
4   0x103080733 WebKit::WebPage::didReceiveWebPageMessage(CoreIPC::Connection*, CoreIPC::MessageID, CoreIPC::ArgumentDecoder*)
5   0x102f81e1d WebKit::WebPage::didReceiveMessage(CoreIPC::Connection*, CoreIPC::MessageID, CoreIPC::ArgumentDecoder*)
6   0x102ffa881 WebKit::WebProcess::didReceiveMessage(CoreIPC::Connection*, CoreIPC::MessageID, CoreIPC::ArgumentDecoder*)
7   0x102eb779c CoreIPC::Connection::dispatchMessage(CoreIPC::Connection::Message<CoreIPC::ArgumentDecoder>&)
8   0x102eb9fb3 CoreIPC::Connection::dispatchMessages()
9   0x102ec0dcb MemberFunctionWorkItem0<CoreIPC::Connection>::execute()
10  0x102f1fe0f RunLoop::performWork()
11  0x102f20d40 RunLoop::performWork(void*)
12  0x1026d6b51 __CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE0_PERFORM_FUNCTION__
13  0x1026d63bd __CFRunLoopDoSources0
14  0x1026fd1a9 __CFRunLoopRun
15  0x1026fcae6 CFRunLoopRunSpecific
16  0x10e44c3d3 RunCurrentEventLoopInMode
17  0x10e45358f ReceiveNextEventCommon
18  0x10e4534ca BlockUntilNextEventMatchingListInMode
19  0x10a05b3f1 _DPSNextEvent
20  0x10a05acf5 -[NSApplication nextEventMatchingMask:untilDate:inMode:dequeue:]
21  0x10a05762d -[NSApplication run]
22  0x102f2102c RunLoop::run()
23  0x10300b18f WebKit::WebProcessMain(WebKit::CommandLine const&)
24  0x102f7683f _ZL10WebKitMainRKN6WebKit11CommandLineE
25  0x102f7672d WebKitMain
26  0x101cfad82 main
27  0x101cfac54 start
28  0x8

Expected result:
2. No assert failure, no crash.

[Alexey Proskuryakov]

This doesn't add up. The stack trace is about navigation (going back or forward), not editing.

Perhaps you have rebuilt updated WebKit while Safari was running against an older revision? That could result in a mismatch like that.

[Dimitris Apostolou]

Adding up or not, this happens every single time.

Welcome to the amazing world of bugs :)

[Dimitris Apostolou]

But indeed, the stack trace is now different. It is a duplicate of another bug I filed. Will add the steps there.

*** This bug has been marked as a duplicate of bug 70422 ***