480970 - Crash [@ nsGlobalWindow::ResumeTimeouts]

Status: RESOLVED DUPLICATE of bug 481955

(Core :: DOM: Core & HTML, defect, P2)

Description

[Martijn Wargers (dead)]

This is a follow-up from bug 480793, I noticed that the patch in that bug didn't fix the crashes I was seeing.

Stack of crash, I'm seeing:
>	gklayout.dll!nsCOMPtr<nsITimer>::assign_assuming_AddRef(nsITimer * newPtr=0x06252ca0)  Line 495 + 0x9 bytes	C++
 	gklayout.dll!nsCOMPtr<nsITimer>::assign_from_helper(const nsCOMPtr_helper & helper={...}, const nsID & aIID={...})  Line 1242	C++
 	gklayout.dll!nsCOMPtr<nsITimer>::operator=(const nsCOMPtr_helper & rhs={...})  Line 708	C++
 	gklayout.dll!nsGlobalWindow::ResumeTimeouts(int aThawChildren=0)  Line 8515	C++
 	gklayout.dll!nsResumeTimeoutsEvent::Run()  Line 156	C++
 	xpcom_core.dll!nsThread::ProcessNextEvent(int mayWait=1, int * result=0x0012f788)  Line 511	C++
 	xpcom_core.dll!NS_ProcessNextEvent_P(nsIThread * thread=0x00cd3b88, int mayWait=1)  Line 230 + 0x16 bytes	C++
 	xpcom_core.dll!nsThread::Shutdown()  Line 465 + 0xb bytes	C++
 	xpcom_core.dll!NS_InvokeByIndex_P(nsISupports * that=0x00000006, unsigned int methodIndex=0, unsigned int paramCount=0, nsXPTCVariant * params=0x0012f830)  Line 102	C++
 	xpcom_core.dll!nsProxyObjectCallInfo::Run()  Line 181 + 0x2d bytes	C++
 	xpcom_core.dll!nsProxyObjectCallInfo::Run()  Line 181 + 0x2d bytes	C++
 	xpcom_core.dll!nsThread::ProcessNextEvent(int mayWait=1, int * result=0x0012f848)  Line 511	C++
 	xpcom_core.dll!NS_ProcessNextEvent_P(nsIThread * thread=0x00cd3b88, int mayWait=1)  Line 230 + 0x16 bytes	C++
 	gkwidget.dll!nsBaseAppShell::Run()  Line 170 + 0xc bytes	C++
 	tkitcmps.dll!nsAppStartup::Run()  Line 192 + 0x1c bytes	C++
 	xul.dll!XRE_main(int argc=1, char * * argv=0x00caffb8, const nsXREAppData * aAppData=0x00caa538)  Line 3220 + 0x25 bytes	C++
 	firefox.exe!NS_internal_main(int argc=1, char * * argv=0x00caffb8)  Line 156 + 0x12 bytes	C++
 	firefox.exe!wmain(int argc=1, unsigned short * * argv=0x00caa058)  Line 107 + 0xd bytes	C++
 	firefox.exe!__tmainCRTStartup()  Line 583 + 0x19 bytes	C
 	firefox.exe!wmainCRTStartup()  Line 403	C
 	kernel32.dll!_BaseProcessStart@4()  + 0x23 bytes	


Also, prior to the crash, I'm seeing this assertion:
###!!! ASSERTION: How'd our timer end up null if we're not frozen?: 'IsFrozen()'
, file c:/mozilla-build-1.3/src/dom/src/base/nsGlobalWindow.cpp, line 7855

Comment 1

[Johnny Stenback (:jst)]

Martijn, are you still seeing this crash with builds from today?

Comment 2

[Martijn Wargers (dead)]

Yes, see: http://crash-stats.mozilla.com/report/index/965760d0-a6a9-46c7-a078-5bdb42090304?p=1

Comment 3

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

(In reply to comment #2)
> Yes, see:
> http://crash-stats.mozilla.com/report/index/965760d0-a6a9-46c7-a078-5bdb42090304?p=1

That is actually different crash. Can you reproduce that with a debug build?
If yes, do you see assertion "No expression, so no handler text!"

Comment 4

[Martijn Wargers (dead)]

No, I can't reproduce that crash with a debug build, I can only reproduce the crash as originally reported.

Comment 6

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

I uploaded a patch to tryserver.
The build will appear here https://build.mozilla.org/tryserver-builds/?C=M;O=D
tca and opettay in its name.

Comment 8

[Johnny Stenback (:jst)]

Blocking, just to make sure we track this if it's really not a dupe.

Comment 9

[Henrik Skupin [:whimboo][⌚️UTC+1]]

Johnny, this is a dupe. Bug 481955 has already blocking1.9.1+ set.

Comment 10

[:Gavin Sharp [email: [e-mail]]]

Johnny added the flag so that it would be marked correctly if the bug was reopened for whatever reason. There's no harm in having a blocking+ flag on a RESOLVED DUPLICATE bug, so you shouldn't have removed it.