304639 - History/frameset related (?) crash

Status: VERIFIED FIXED

(Core :: DOM: Navigation, defect)

Description

[Ere Maijala (slow)]

SeaMonkey trunk builds as well as latest Deer Park Alpha builds crash with the
following steps:

1. Go to http://www.akiba.fi/
2. Click "PC KOMPONENTIT" on the left pane
3. Click an item on the right frame (such as "Intel PRO 2200 ADSL-modeemi PCI")
4. Click the back button
5. Click "PROJEKTORIT/TV" on the left pane
6. Observe crash or almost complete loss of responsivity

The observed behavior seems to depend on which item I click (at least Zalman
CNPS7000B-Cu causes a crash) in step 3. Here is a call stack for the crash:

>	xpcom_core.dll!nsQueryInterface::operator()(const nsID & aIID={...}, void * *
answer=0x0013f3e0)  Line 47 + 0x15	C++
 	docshell.dll!nsCOMPtr<nsISHContainer>::assign_from_qi(nsQueryInterface
qi={...}, const nsID & aIID={...})  Line 1232 + 0x11	C++
 
docshell.dll!nsCOMPtr<nsISHContainer>::nsCOMPtr<nsISHContainer>(nsQueryInterface
qi={...})  Line 646	C++
 	docshell.dll!nsDocShell::WalkHistoryEntries(nsISHEntry *
aRootEntry=0x03a45b78, nsDocShell * aRootShell=0x036967b0, unsigned int
(nsISHEntry *, nsDocShell *, int, void *)* aCallback=0x02847c60, void *
aData=0x0013f47c)  Line 7495	C++
 	docshell.dll!nsDocShell::SetChildHistoryEntry(nsISHEntry * aEntry=0x03a45b78,
nsDocShell * aShell=0x036967b0, int aEntryIndex=0, void * aData=0x0013f4c4) 
Line 7668 + 0x16	C++
 	docshell.dll!nsDocShell::SetHistoryEntry(nsCOMPtr<nsISHEntry> *
aPtr=0x03a45abc, nsISHEntry * aEntry=0x04c13d98)  Line 7714 + 0x13	C++
 	docshell.dll!nsDocShell::Embed(nsIContentViewer * aContentViewer=0x04c4a208,
const char * aCommand=0x0289d55d, nsISupports * aExtraInfo=0x00000000)  Line
4464	C++
 	docshell.dll!nsDocShell::CreateContentViewer(const char *
aContentType=0x04d21738, nsIRequest * request=0x03a49588, nsIStreamListener * *
aContentHandler=0x04cd27e8)  Line 5477 + 0x26	C++
 	docshell.dll!nsDSURIContentListener::DoContent(const char *
aContentType=0x04d21738, int aIsContentPreferred=1, nsIRequest *
request=0x03a49588, nsIStreamListener * * aContentHandler=0x04cd27e8, int *
aAbortProcess=0x0013f654)  Line 130 + 0x1e	C++
 	docshell.dll!nsDocumentOpenInfo::TryContentListener(nsIURIContentListener *
aListener=0x03a45f88, nsIChannel * aChannel=0x03a49588)  Line 774 + 0x42	C++
 	docshell.dll!nsDocumentOpenInfo::DispatchContent(nsIRequest *
request=0x03a49588, nsISupports * aCtxt=0x00000000)  Line 500 + 0x39	C++
 	docshell.dll!nsDocumentOpenInfo::OnStartRequest(nsIRequest *
request=0x03a49588, nsISupports * aCtxt=0x00000000)  Line 345 + 0x10	C++
 	necko.dll!nsHttpChannel::CallOnStartRequest()  Line 748 + 0x42	C++
 	necko.dll!nsHttpChannel::ProcessNormal()  Line 916 + 0x8	C++
 	necko.dll!nsHttpChannel::ProcessResponse()  Line 802 + 0x8	C++
 	necko.dll!nsHttpChannel::OnStartRequest(nsIRequest * request=0x04cc5d30,
nsISupports * ctxt=0x00000000)  Line 3957 + 0xb	C++
 	necko.dll!nsInputStreamPump::OnStateStart()  Line 381 + 0x2a	C++
 	necko.dll!nsInputStreamPump::OnInputStreamReady(nsIAsyncInputStream *
stream=0x04cc5ae0)  Line 337 + 0xb	C++
 	xpcom_core.dll!nsInputStreamReadyEvent::EventHandler(PLEvent *
plevent=0x04c6cee4)  Line 120	C++
 	xpcom_core.dll!PL_HandleEvent(PLEvent * self=0x04c6cee4)  Line 688 + 0xa	C
 	xpcom_core.dll!PL_ProcessPendingEvents(PLEventQueue * self=0x00a29eb0)  Line
623 + 0x9	C
 	xpcom_core.dll!_md_EventReceiverProc(HWND__ * hwnd=0x001d09ea, unsigned int
uMsg=49532, unsigned int wParam=0, long lParam=10657456)  Line 1408 + 0x9	C

Comment 1

[Ere Maijala (slow)]

Attachment: Call Stack for the crash

Sorry about the ugly stack in the first place. Here is one you can see better.

Comment 2

[Hermann Schwab]

Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.9a1) Gecko/20050814 SeaMonkey/1.0a
Talkback TB8368688G 
will take some hours, as currently there are 15000 waiting to be processed

Comment 3

[OstGote!]

Looks like Bug 303606 has the same crash stack. 

Comment 4

[OstGote!]

Seamonkey trunk build 2005081505 on WinXP: Talkback TB8405859K.

Comment 5

[Hermann Schwab]

TB8397358 looks nice, MozillaTrunk Build ID 2005081405 Win98
others can be found looking for the URL
http://talkback-public.mozilla.org/talkback/fastfind.jsp?search=1&searchby=url&match=contains&searchfor=akiba.fi&vendor=All&product=All&platform=All&buildid=&sdate=&stime=&edate=&etime=&sortby=bbid

Comment 6

[Hermann Schwab]

Regression: wfm 1.8b4: 2005081006 -- crash 1.8b4: 2005081106

Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.8b4) Gecko/20050810 Firefox/1.0+
Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.8b4) Gecko/20050811 Firefox/1.0+

Talkback TB8397358 has symbols, MozillaTrunk Build ID 2005081405 (Seamonkey)
Talkback TB8400535 has offsets only into DOCSHELL and NECKO, Build ID 2005081505
(Seamonkey)

Regression found using Firefox, checkins for SeamonkeyAll:
http://bonsai.mozilla.org/cvsquery.cgi?treeid=default&module=SeaMonkeyAll&branch=HEAD&branchtype=match&dir=&file=&filetype=match&who=&whotype=match&sortby=Date&hours=2&date=explicit&mindate=2005-08-10+00%3A00&maxdate=2005-08-11+06%3A00&cvsroot=%2Fcvsroot

Comment 7

[Mike Schroepfer]

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

Comment 8

[Mats Palmgren (inactive)]

REOPEN, I think this might be different from bug 303606.

The regression range I get is 2005-08-03-10 -- 2005-08-04-07 (SeaMonkey Linux)
In that span bug 301397 looks like the culprit and after backing those changes
out I could not reproduce the crash in a local Linux SeaMonkey debug build.
FWIW, I can't even reproduce the bug this was duped against.

Comment 9

[Mats Palmgren (inactive)]

Bryner, this looks like a regression from bug 301397

Comment 10

[Mats Palmgren (inactive)]

Attachment: Like so?

I'm not sure if this is the real fix or just wallpaper.
What happens is that mOSHE == aOldEntry and it's the last ref so it's deleted:

void
nsDocShell::SwapHistoryEntries(nsISHEntry *aOldEntry, nsISHEntry *aNewEntry)
{
    if (aOldEntry == mOSHE)
	mOSHE = aNewEntry;

    if (aOldEntry == mLSHE)
	mLSHE = aNewEntry;
}

Comment 11

[Brian Ryner (not reading)]

Comment on attachment 192941 [details] [diff] [review]
Like so?

I think it would be cleaner to make oldRootEntry be a nsCOMPtr in
SetHistoryEntry().  In all other cases, when SetChildHistoryEntry is called,
WalkHistoryEntries is already holding a ref to aEntry (childEntry).

Comment 12

[Mats Palmgren (inactive)]

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

Comment 13

[Mats Palmgren (inactive)]

Attachment: Patch rev. 2

Comment 14

[Mats Palmgren (inactive)]

Checked in to trunk and 1.8 branch at 2005-08-21 05:43 PDT

-> FIXED