694646 - crash [@ nsXULWindow::GetDocShell(nsIDocShell**)] [fixed by bug 679626]

Status: RESOLVED FIXED

(Core :: XUL, defect)

Description

[Wayne Mery (:wsmwk)]

crash [@ nsXULWindow::GetDocShell(nsIDocShell**)]
#2 crash for tbird 7.0.2. but almost zero for Firefox.
only #34 for Mac 7.0.2

user for bp-c1e81b9d-1073-4647-97bc-277222111014 has several crash sigs:
1. this bug
2. nsRefPtr<nsTypedSelection>::~nsRefPtr<nsTypedSelection>() | nsInterfaceRequestorAgg::Release()  -- bug 692981
3. nsMsgProtocol::CloseSocket() -- bug 673438 

bp-c1e81b9d-1073-4647-97bc-277222111014
EXCEPTION_ACCESS_VIOLATION_READ
0x4de85ee4
I had Thunderbird open, but I was not using it at the time that it crashed. I have no idea what caused this...
0	xul.dll	nsXULWindow::GetDocShell	netwerk/protocol/http/HttpBaseChannel.cpp:1094
1	xul.dll	GetDOMWindow	xpfe/appshell/src/nsAppShellWindowEnumerator.cpp:70
2	xul.dll	nsASDOMWindowEnumerator::GetNext	xpfe/appshell/src/nsAppShellWindowEnumerator.cpp:260
3	xul.dll	MarkWindowList	content/base/src/nsCCUncollectableMarker.cpp:177
4	xul.dll	nsCCUncollectableMarker::Observe	content/base/src/nsCCUncollectableMarker.cpp:224
5	xul.dll	nsObserverList::NotifyObservers	xpcom/ds/nsObserverList.cpp:130 

two more examples:
bp-bc2ff3d1-d447-4fbc-8695-cbf722111014
EXCEPTION_ACCESS_VIOLATION_READ
0x4
I was attached some photos to an email. I selected multiple photos, right clicked on the selection, chose Send To -> Mail Recipient. It gave me the option to convert the pictures to 1280 x1024. It crashed once Thunderbird opened.
0	xul.dll	nsXULWindow::GetDocShell	netwerk/protocol/http/HttpBaseChannel.cpp:1094
1	xul.dll	GetDOMWindow	xpfe/appshell/src/nsAppShellWindowEnumerator.cpp:70
2	xul.dll	nsASDOMWindowEnumerator::GetNext	xpfe/appshell/src/nsAppShellWindowEnumerator.cpp:260
3	xul.dll	MarkWindowList	content/base/src/nsCCUncollectableMarker.cpp:177
4	xul.dll	nsCCUncollectableMarker::Observe	content/base/src/nsCCUncollectableMarker.cpp:224
5	xul.dll	nsObserverList::NotifyObservers	xpcom/ds/nsObserverList.cpp:130 

bp-c1e81b9d-1073-4647-97bc-277222111014
EXCEPTION_ACCESS_VIOLATION_READ
0x4de85ee4
I had Thunderbird open, but I was not using it at the time that it crashed. I have no idea what caused this...
0	xul.dll	nsXULWindow::GetDocShell	netwerk/protocol/http/HttpBaseChannel.cpp:1094
1	xul.dll	GetDOMWindow	xpfe/appshell/src/nsAppShellWindowEnumerator.cpp:70
2	xul.dll	nsASDOMWindowEnumerator::GetNext	xpfe/appshell/src/nsAppShellWindowEnumerator.cpp:260
3	xul.dll	MarkWindowList	content/base/src/nsCCUncollectableMarker.cpp:177
4	xul.dll	nsCCUncollectableMarker::Observe	content/base/src/nsCCUncollectableMarker.cpp:224
5	xul.dll	nsObserverList::NotifyObservers	xpcom/ds/nsObserverList.cpp:130

Comment 1

[Wayne Mery (:wsmwk)]

huge uptick *starting* roughly Aug 31/Sept 1
regression?
AV software?

Correlations:
EXCEPTION_ACCESS_VIOLATION_READ (410)
72% (294/410) vs.  45% (5044/11206) FWPUCLNT.DLL
76% (313/410) vs.  51% (5701/11206) linkinfo.dll
71% (292/410) vs.  46% (5166/11206) profapi.dll
75% (306/410) vs.  51% (5701/11206) wship6.dll
71% (292/410) vs.  48% (5378/11206) slc.dll
71% (292/410) vs.  48% (5386/11206) srvcli.dll
58% (237/410) vs.  35% (3905/11206) ksuser.dll

Users claim crashes are random

Comment 2

[Wayne Mery (:wsmwk)]

bz, can you have a look at this?

Comment 3

[Boris Zbarsky [:bzbarsky]]

What does this have to do with networking?  Or was that just a misassignment?  note that nsXULWindow::GetDocshell is most definitely NOT in HttpBaseChannel.cpp.  That's just breakpad lying to you.

I have no idea what's up here other than "someone is holding on to a dead XULWindow or something".

That's assuming the frame 0 filename is the only bogus thing in the stack.  Who knows what else is bogus there.

Comment 4

[(not currently active) Ted Mielczarek]

The top of the stack seems correct. The source link is wrong, but I think that's just Breakpad getting confused by ICF. (GetDocShell is a pretty simple function, it seems pretty likely to get folded together with other functions that produce exactly the same code.)

If you look at the source at frame 1:
http://hg.mozilla.org/releases/mozilla-release/annotate/58f3edbff1b9/xpfe/appshell/src/nsAppShellWindowEnumerator.cpp#l70

It's clearly calling nsIXULWindow::GetDocShell. The rest of the stack leading up to there looks totally sensible: the cycle collector timer fires, we run some CC code, it enumerates a set of windows, which winds up crashing there.

The crash address isn't NULL or near-null, so maybe there's a refcount error somewhere that's causing a window to be released too early?

Comment 5

[Wayne Mery (:wsmwk)]

stack of firefox crash bp-c1e81b9d-1073-4647-97bc-277222111014 essentially matches tbird crash deafd437-41fb-4fc6-807f-9a9932111012

Comment 7

[Wayne Mery (:wsmwk)]

This crash signature no longer exists after TB13. So it is gone (which I doubt) or morphed.  

Anyway, it will be nice to have bug 679626 fixed

Comment 8

[Scoobidiver (away)]

It's #10 top crasher in TB 17.0.2.

Comment 9

[Wayne Mery (:wsmwk)]

(In reply to Scoobidiver from comment #8)
> It's #10 top crasher in TB 17.0.2.

totally gone in 17.0.3.

Nothing in Thunderbird checkins should have fixed it - https://bugzilla.mozilla.org/buglist.cgi?quicksearch=ALL%20tracking_thunderbird_esr17%3A%2219%2B%22%20%20status_thunderbird_esr17%3Afixed;list_id=5769021

But there is a crash sig in 17.0.3 with the same ranking that does not exist *at all* in 17.0.2 
nsMimeBaseEmitter::GetOutputListener(nsIStreamListener**)
https://crash-stats.mozilla.com/report/list?product=Thunderbird&query_search=signature&query_type=contains&query=nsMimeBaseEmitter%3A%3AGetOutputListener%28nsIStreamListener**%29&reason_type=contains&date=02%2F26%2F2013%2015%3A41%3A22&range_value=4&range_unit=weeks&hang_type=any&process_type=any&do_query=1&admin=1&signature=nsMimeBaseEmitter%3A%3AGetOutputListener%28nsIStreamListener**%29

What the heck is going on ?

Comment 10

[Scoobidiver (away)]

(In reply to Wayne Mery (:wsmwk) from comment #9)
> totally gone in 17.0.3.
Removing the topcrash keyword.

Comment 11

[Makoto Kato [:m_kato]]

add 17.0.6 signature

Comment 12

[Wayne Mery (:wsmwk)]

No crashes newer than version 17.0.6 for nsMimeBaseEmitter::GetOutputListener(nsIStreamListener**) or containing nsMimeBaseEmitter::GetOutputListener .  (And still nothing containing nsXULWindow::GetDocShell)

I haven't completely checked the time lines enough to determine if this was fixed by bug 679626 - landed in mozilla 19 and  Standard8 landed on ESR around 2013-01-02.  so did bug 679626 hit 17.0.3?  (ref comment 9)

Comment 13

[Firefox Bug Husbandry Bot]

Moving to Core:XUL per https://bugzilla.mozilla.org/show_bug.cgi?id=1455336