575100 - crash [@ xul.dll@0x1a4b8b ]

Status: RESOLVED DUPLICATE of bug 537630

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

Description

[Miroslav Policki]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.4) Gecko/20100611 Firefox/3.6.4 (.NET CLR 3.5.30729)
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.4) Gecko/20100611 Firefox/3.6.4 (.NET CLR 3.5.30729)

I have about 360 tabs open. Firefox is always running, as is my computer (except for standbys and hibernations). I don't know how to reproduce it.

Reproducible: Didn't try




Crash report: bp-3d541f40-ef6f-4fba-9c8b-b89bd2100623

Comment 1

[(mostly gone) XtC4UaLL [:xtc4uall]]

Signature	xul.dll@0x1a4b8b
UUID	3d541f40-ef6f-4fba-9c8b-b89bd2100623
Time 	2010-06-23 15:25:00.946955
Uptime	12102
Last Crash	12174 seconds (3.4 hours) before submission
Install Age	684040 seconds (1.1 weeks) since version was first installed.
Product	Firefox
Version	3.6.4
Build ID	20100611143157
Branch	1.9.2
OS	Windows NT
OS Version	6.1.7600
CPU	x86
CPU Info	GenuineIntel family 6 model 23 stepping 6
Crash Reason	EXCEPTION_ACCESS_VIOLATION
Crash Address	0xffffffffc924fe9b
User Comments	
Processor Notes 	
EMCheckCompatibility	False

Frame  	Module  	Signature  	Source
0 	xul.dll 	xul.dll@0x1a4b8b 	
1 	xul.dll 	xul.dll@0x1735a8 	
2 	xul.dll 	xul.dll@0x806af 	
3 	xul.dll 	xul.dll@0xa4a76 	
4 	xul.dll 	xul.dll@0xa4bdf 	
5 	xul.dll 	xul.dll@0xefa7f 	
6 	xul.dll 	xul.dll@0x169398 	
7 	xul.dll 	xul.dll@0x9b13af 	
8 	xul.dll 	xul.dll@0x9b4607 	
9 	xul.dll 	xul.dll@0x244872 	
10 	mozcrt19.dll 	malloc 	obj-firefox/memory/jemalloc/crtsrc/jemalloc.c:5790
11 	xul.dll 	xul.dll@0x30f133 	
12 	xul.dll 	xul.dll@0x3545b0 	
13 	firefox.exe 	firefox.exe@0x1b97 	
14 	ntdll.dll 	ntdll.dll@0x7041c 	
15 	ntdll.dll 	ntdll.dll@0x39d44 	
16 	firefox.exe 	firefox.exe@0x183f 	
17 	firefox.exe 	firefox.exe@0x183f

Comment 2

[Miroslav Policki]

I have two new crashes, but their signature is [@ xul.dll@0x864ba ] (also, Firefox version is 3.6.6, build ID 20100625231939) so I'm not sure if they should be in a new bug. Anyway, here are the crash reports:
bp-dbf9b693-7cf1-46e5-9934-6856c2100629
bp-81da1add-5575-401c-b1e7-d86322100629

Comment 3

[timeless]

ted: xul.dll doesn't have a debug id, what gives?

Comment 4

[(not currently active) Ted Mielczarek]

You CCed me on another bug like this, where I was able to download the .dmp and get a stack with Visual C++. Might be a Breakpad bug. I still have the other dump, I just haven't had time to figure it out.

Comment 5

[(not currently active) Ted Mielczarek]

http://hg.mozilla.org/releases/mozilla-1.9.2/annotate/c07c6c1b5071/dom/base/nsJSTimeoutHandler.cpp#l301

Stack:
ChildEBP RetAddr  
0039f2cc 68bfc4d9 xul!nsJSScriptTimeoutHandler::SetLateness(unsigned int aHowLate = 0x17d63)+0x45 [e:\builds\moz2_slave\win32_build\build\dom\base\nsjstimeouthandler.cpp @ 301]
0039f390 68b199f1 xul!nsGlobalWindow::RunTimeout(struct nsTimeout * aTimeout = 0x1d4e9300)+0x259 [e:\builds\moz2_slave\win32_build\build\dom\base\nsglobalwindow.cpp @ 8127]
0039f3a8 68c24e67 xul!nsGlobalWindow::TimerCallback(class nsITimer * aTimer = 0x21c796a0, void * aClosure = 0x1d4e9300)+0x17 [e:\builds\moz2_slave\win32_build\build\dom\base\nsglobalwindow.cpp @ 8471]
0039f3c0 68c24dd0 xul!nsTimerImpl::Fire(void)+0x87 [e:\builds\moz2_slave\win32_build\build\xpcom\threads\nstimerimpl.cpp @ 427]
0039f3c8 68bd9100 xul!nsTimerEvent::Run(void)+0x20 [e:\builds\moz2_slave\win32_build\build\xpcom\threads\nstimerimpl.cpp @ 521]
0039f3f8 68bf4f99 xul!nsThread::ProcessNextEvent(int mayWait = <Memory access error>, int * result = <Memory access error>)+0x210 [e:\builds\moz2_slave\win32_build\build\xpcom\threads\nsthread.cpp @ 533]
0039f438 68cdf027 xul!mozilla::ipc::MessagePump::Run(class base::MessagePump::Delegate * aDelegate = <Memory access error>)+0x69 [e:\builds\moz2_slave\win32_build\build\ipc\glue\messagepump.cpp @ 118]
0039f474 68cdefef xul!MessageLoop::RunHandler(void)+0x26 [e:\builds\moz2_slave\win32_build\build\ipc\chromium\src\base\message_loop.cc @ 200]
0039f4ac 68cc650e xul!MessageLoop::Run(void)+0x1f [e:\builds\moz2_slave\win32_build\build\ipc\chromium\src\base\message_loop.cc @ 174]
0039f4b8 68cdedd6 xul!nsBaseAppShell::Run(void)+0x34 [e:\builds\moz2_slave\win32_build\build\widget\src\xpwidgets\nsbaseappshell.cpp @ 180]
0039f4c4 68abfb02 xul!nsAppStartup::Run(void)+0x1e [e:\builds\moz2_slave\win32_build\build\toolkit\components\startup\src\nsappstartup.cpp @ 184]
0039f76c 00d4133b xul!XRE_main(int argc = 1, char ** argv = 0x026290a8, struct nsXREAppData * aAppData = 0x02616300)+0xdc1 [e:\builds\moz2_slave\win32_build\build\toolkit\xre\nsapprunner.cpp @ 3485]

argc has some bogus value, 0x628f05c0

Comment 6

[(not currently active) Ted Mielczarek]

FWIW, I poked at the dump with Breakpad and I think the CodeView record really is missing for xul.dll, so Breakpad has no way to locate the debug symbols. Debuggers (WinDBG/Visual C++) can find it because I have the binaries available, and they have the code identifier, so they can read the binary, pull the CodeView record from there, and then use that to locate the symbols.

I think we could add a capability like this to Breakpad, if in the process of dumping symbols we took the code identifier and left a breadcrumb trail in the symbol tree from that ID pointing to the debug id. I'll follow up in bug 528092 since that's related.