Closed
Bug 575100
Opened 14 years ago
Closed 14 years ago
crash [@ xul.dll@0x1a4b8b ]
Categories
(Core :: DOM: Core & HTML, defect)
Tracking
()
RESOLVED
DUPLICATE
of bug 537630
People
(Reporter: miroslav.policki+mozillabugzilla, Unassigned)
Details
(Keywords: crash)
Crash Data
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•14 years ago
|
||
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
Keywords: crash
Reporter | ||
Comment 2•14 years ago
|
||
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 4•14 years ago
|
||
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•14 years ago
|
||
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
Component: General → DOM
Product: Firefox → Core
QA Contact: general → general
Version: unspecified → 1.9.2 Branch
Comment 6•14 years ago
|
||
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.
Status: UNCONFIRMED → RESOLVED
Closed: 14 years ago
Resolution: --- → DUPLICATE
Assignee | ||
Updated•13 years ago
|
Crash Signature: [@ xul.dll@0x1a4b8b ]
Assignee | ||
Updated•5 years ago
|
Component: DOM → DOM: Core & HTML
You need to log in
before you can comment on or make changes to this bug.
Description
•