307241 - ASSERTION: Adding child where we already have a child? @ nsSHEntry::AddChild

Status: RESOLVED FIXED

(Core :: DOM: Navigation, defect)

Description

[Bob Clary [:bc] (inactive)]

Found using a Firefox 1.5 Debug build from 2005-09-05 on WinXP and Win2k+3.

###!!! ASSERTION: Adding child where we already have a child?  This will likely
misbehave: 'Error', file c:/work/mozilla/builds/ff/1.5/mozilla/xpfe/components/s
history/src/nsSHEntry.cpp, line 488

nsSHEntry::AddChild(nsSHEntry * const 0x0311b354, nsISHEntry * 0x03a6c188, int
0x00000001) line 488 + 26 bytes
nsDocShell::AddChildSHEntry(nsDocShell * const 0x02968e64, nsISHEntry *
0x031ab2b0, nsISHEntry * 0x03a6c188, int 0x00000001) line 2572 + 31 bytes
nsDocShell::AddChildSHEntry(nsDocShell * const 0x0342e93c, nsISHEntry *
0x031ab2b0, nsISHEntry * 0x03a6c188, int 0x00000001) line 2621 + 35 bytes
nsDocShell::DoAddChildSHEntry(nsISHEntry * 0x03a6c188, int 0x00000001) line 2641
+ 46 bytes
nsDocShell::AddToSessionHistory(nsIURI * 0x03203410, nsIChannel * 0x03abb120,
nsISHEntry * * 0x0347eb0c) line 7433 + 33 bytes
nsDocShell::OnNewURI(nsIURI * 0x03203410, nsIChannel * 0x03abb120, unsigned int
0x08000001, int 0x00000000, int 0x00000001) line 7197 + 61 bytes
nsDocShell::OnLoadingSite(nsIChannel * 0x03abb120, int 0x00000000, int
0x00000001) line 7245 + 39 bytes
nsDocShell::CreateContentViewer(nsDocShell * const 0x0347e978, const char *
0x03a6d4b0, nsIRequest * 0x03abb120, nsIStreamListener * * 0x03ab7d20) line 5512
+ 21 bytes
nsDSURIContentListener::DoContent(nsDSURIContentListener * const 0x0347eda8,
const char * 0x03a6d4b0, int 0x00000000, nsIRequest * 0x03abb120,
nsIStreamListener * * 0x03ab7d20, int * 0x0012f494) line 130 + 30 bytes
nsDocumentOpenInfo::TryContentListener(nsIURIContentListener * 0x0347eda8,
nsIChannel * 0x03abb120) line 774 + 66 bytes
nsDocumentOpenInfo::DispatchContent(nsIRequest * 0x03abb120, nsISupports *
0x00000000) line 500 + 57 bytes
nsDocumentOpenInfo::OnStartRequest(nsDocumentOpenInfo * const 0x03ab7d10,
nsIRequest * 0x03abb120, nsISupports * 0x00000000) line 345 + 16 bytes
nsHttpChannel::CallOnStartRequest() line 752 + 66 bytes
nsHttpChannel::ProcessNormal() line 920 + 8 bytes
nsHttpChannel::ProcessResponse() line 806 + 8 bytes
nsHttpChannel::OnStartRequest(nsHttpChannel * const 0x03abb128, nsIRequest *
0x03aba350, nsISupports * 0x00000000) line 3966 + 11 bytes
nsInputStreamPump::OnStateStart() line 381 + 42 bytes
nsInputStreamPump::OnInputStreamReady(nsInputStreamPump * const 0x03aba354,
nsIAsyncInputStream * 0x030ac340) line 337 + 11 bytes
nsInputStreamReadyEvent::EventHandler(PLEvent * 0x03aba444) line 120
PL_HandleEvent(PLEvent * 0x03aba444) line 688 + 10 bytes
PL_ProcessPendingEvents(PLEventQueue * 0x00b4abb8) line 623 + 9 bytes
_md_EventReceiverProc(HWND__ * 0x00080144, unsigned int 0x0000c0f0, unsigned int
0x00000000, long 0x00b4abb8) line 1408 + 9 bytes
USER32! 77d48734()
USER32! 77d48816()
USER32! 77d489cd()
USER32! 77d48a10()
nsAppShell::Run(nsAppShell * const 0x00b80458) line 135
nsAppStartup::Run(nsAppStartup * const 0x00b803b8) line 145 + 26 bytes
XRE_main(int 0x00000001, char * * 0x003f6e20, const nsXREAppData * 0x0042201c
kAppData) line 2322 + 35 bytes
main(int 0x00000001, char * * 0x003f6e20) line 61 + 18 bytes
mainCRTStartup() line 338 + 17 bytes

Comment 1

[Bob Clary [:bc] (inactive)]

(In reply to comment #0)
This stack is probably entirely bogus. I will try to get a good one later today.

Comment 2

[Jesse Ruderman]

I got the same assertion message on trunk at https://adwords.google.com/select/.

Comment 3

[Bob Clary [:bc] (inactive)]

I no longer get this assertion on the top sites or
https://adwords.google.com/select/, but consistently get it on several of the
dom test suites in both 1.8 branch and trunk. Load the above URL and click Load
JSUnit. 

Comment 4

[Bob Clary [:bc] (inactive)]

Attachment: stack

The assertion fires several times with similar stacks.

Comment 5

[Frank Wein [:mcsmurf]]

This is probably a regression right?

Comment 6

[Frank Wein [:mcsmurf]]

Attachment: Testcase

Minimal testcase, load, wait a few seconds and it should assert. If i put the
meta reload tag within the frame, it does not assert (so only meta reload on
the main page with the frameset asserts).

Comment 7

[Jesse Ruderman]

WFM with Frank's testcase, Mac trunk.

Comment 8

[Jesse Ruderman]

I can reproduce with the testcase in bug 344216, though.

Comment 9

[Daniel Holbert [:dholbert]]

I still get the assertion using Frank's testcase on Linux trunk.

Comment 10

[Daniel Holbert [:dholbert]]

The testcases on Bug 388058 trigger this assertion as well. 
(see https://bugzilla.mozilla.org/show_bug.cgi?id=388058#c10)

Comment 12

[Boris Zbarsky [:bzbarsky]]

Uh.... This doesn't look like a duplicate at all.  Reopening.

Comment 13

[Olli Pettay [:smaug][[e-mail]]]

Fixed (by bug 462076)