Bug 51224 - ASSERT hit in HistoryItem::addChildItem
Summary: ASSERT hit in HistoryItem::addChildItem
Status: RESOLVED WORKSFORME
Alias: None
Product: WebKit
Classification: Unclassified
Component: History (show other bugs)
Version: 528+ (Nightly build)
Hardware: PC OS X 10.5
: P2 Normal
Assignee: Nobody
URL:
Keywords:
: 73752 (view as bug list)
Depends on:
Blocks:
 
Reported: 2010-12-16 17:59 PST by Ryosuke Niwa
Modified: 2016-08-03 13:45 PDT (History)
10 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Ryosuke Niwa 2010-12-16 17:59:59 PST
I hit the following assertion on facebook:

void HistoryItem::addChildItem(PassRefPtr<HistoryItem> child)
{
    ASSERT(!childItemWithTarget(child->target())); // < this one
    m_children.append(child);
#if PLATFORM(ANDROID)
    notifyHistoryItemChanged(this);
#endif
}

Stack trace:
#0	0x10192f18d in WebCore::HistoryItem::addChildItem at HistoryItem.cpp:419
#1	0x10192d387 in WebCore::HistoryController::createItemTree at HistoryController.cpp:543
#2	0x10192d49e in WebCore::HistoryController::pushState at HistoryController.cpp:659
#3	0x10192b98e in WebCore::History::stateObjectAdded at History.cpp:106
#4	0x101b80f99 in WebCore::JSHistory::pushState at JSHistoryCustom.cpp:183
#5	0x101b800e0 in WebCore::jsHistoryPrototypeFunctionPushState at JSHistory.cpp:182
#6	0x5f84352001b8 in ??
#7	0x1007e84a3 in JSC::JITCode::execute at JITCode.h:77
#8	0x1007e32a5 in JSC::Interpreter::executeCall at Interpreter.cpp:849
#9	0x10079c9b4 in JSC::call at CallData.cpp:38
#10	0x101ace843 in WebCore::JSMainThreadExecState::call at JSMainThreadExecState.h:48
#11	0x101b6db7c in WebCore::JSEventListener::handleEvent at JSEventListener.cpp:124
#12	0x10183fe3e in WebCore::EventTarget::fireEventListeners at EventTarget.cpp:342
#13	0x1018404a8 in WebCore::EventTarget::fireEventListeners at EventTarget.cpp:311
#14	0x101dbef35 in WebCore::Node::handleLocalEvents at Node.cpp:2511
#15	0x101dbe98c in WebCore::Node::dispatchGenericEvent at Node.cpp:2636
#16	0x101dbee65 in WebCore::Node::dispatchEvent at Node.cpp:2580
#17	0x10183f9b8 in WebCore::EventTarget::dispatchEvent at EventTarget.cpp:289
#18	0x10182c64c in WebCore::EventHandler::keyEvent at EventHandler.cpp:2378
#19	0x101839d55 in WebCore::EventHandler::keyEvent at EventHandlerMac.mm:148
#20	0x100f994db in -[WebHTMLView keyDown:] at WebHTMLView.mm:4217
Comment 1 Ryosuke Niwa 2010-12-16 18:00:39 PST
I've caught in my debugger and will keep it alive until tomorrow morning.  Please ping me (rniwa) on IRC if you're interested in proving it via gdb.
Comment 2 Mihai Parparita 2010-12-17 10:15:35 PST
This appears to happen when l view a friend's profile and then click on one of the mutual friends from the sidebar. IIRC each profile page has a hidden iframe (used for uploads), those are added/removed during profile -> profile navigations (which also involve pushState).

Adding Charlie since I recall this working before, perhaps http://trac.webkit.org/changeset/72566 or http://trac.webkit.org/changeset/71437 triggered this?
Comment 3 Charles Reis 2010-12-20 11:58:59 PST
(In reply to comment #2)
> This appears to happen when l view a friend's profile and then click on one of the mutual friends from the sidebar. IIRC each profile page has a hidden iframe (used for uploads), those are added/removed during profile -> profile navigations (which also involve pushState).
> 
> Adding Charlie since I recall this working before, perhaps http://trac.webkit.org/changeset/72566 or http://trac.webkit.org/changeset/71437 triggered this?

I don't think those CLs would have affected the child's targets, but I'm willing to check.  However, I'm not able to reproduce on Facebook using those steps.  I've tried in Chrome 9.0.597.19 (beta) and a recent build of WebKit.

Do you have a simpler repro yet that I could try?
Comment 4 Mihai Parparita 2011-12-05 13:29:20 PST
*** Bug 73752 has been marked as a duplicate of this bug. ***
Comment 5 Greg Thompson 2012-01-13 13:22:02 PST
I have a reliable repro with a debug build of Chrome Frame 16.0.912.75 (currently on the stable channel).  I do little more than sign into facebook and click on a few things.  What does it mean for there to be two child items with the same target?
Comment 6 Sergio Villar Senin 2012-01-17 09:00:27 PST
We're hitting this also in the WebKitGtk+ port quite often browsing fbook.
Comment 7 Naveen Bobbili 2012-03-08 22:08:11 PST
I observed the same crash while browsing facebook today.
Comment 8 Naveen Bobbili 2012-03-08 22:09:47 PST
Additional Info:
Observed on chrome 16.0.912.77
Comment 9 Brent Fulgham 2016-08-03 13:41:58 PDT
I do not see this issue with any Safari variant, or MiniBrowser.

Is anyone still encountering this under EFL or another port?

I'm closing this bug. Please reopen if you have a reproducible test case.