Closed
Bug 526843
Opened 15 years ago
Closed 13 years ago
Massive increase in random crashes after upgrade to Firefox 3.5.4 - OOM? [@ NoteJSChild - js_TraceObject]
Categories
(Core :: XPConnect, defect)
Tracking
()
RESOLVED
WORKSFORME
People
(Reporter: galar71, Unassigned)
Details
(Keywords: crash)
Crash Data
Attachments
(4 files)
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.4) Gecko/20091016 Firefox/3.5.4 (.NET CLR 3.5.30729) Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.4) Gecko/20091016 Firefox/3.5.4 (.NET CLR 3.5.30729) Hi there... Firefox crashes randomly, and it started happening soon (don't recall exactly how long - could've been the same day) after upgrading to Firefox 3.5.4. It has been happening for about 1-2 weeks. Before this, it would crash occationally, but never in the same day, and rarely in the same week. The crashes appear very random, and they happen both with and without any user input. In other words, it seems to happen on random pages (with/without flash, java or other non-regular content). It just as frequently crahes when I'm away from the computer, as when I'm using the computer (other program or Firefox itself) - totally random. When I have observed the crashes while using Firefox, the application (Firefox) hangs completely for a few seconds, I believe the CPU spikes, and then it crashes. I'm not sure if the CPU spikes every time though, because it often happens when I'm not using Firefox. I have not recently made any major changes to the add-ons or theme, and after it started happening, I have also disabled several of the latest add-ons. Therefore, I find it more likely that it's related the browser and not any of the add-ons, but that can't be determined for sure. I am a software engineer by trade, and I have not been able to find a pattern to the crashes. It is however worth noting that I usually have about 40 or so tabs open. Another thing worth noting is that there seems to be a memory leak as it slowly gobbles up memory, but then again, that has been the case with all Firefox 3.5 releases, so it's not necessarily related to the crashes. For the first several days (maybe a week or so), it crashed without opening the Crash Reporter when it crashes. However, in the last 3 days it's started opening the Crash Reporter when it crashes, so I have submitted Crash Reports. Here's a list of URL's to several different crash reports: - http://crash-stats.mozilla.com/report/index/bp-18197741-f6af-4faa-9ceb-d88562091105 - http://crash-stats.mozilla.com/report/index/bp-9f2cb221-f5e3-4618-a38b-b3fb32091105 - http://crash-stats.mozilla.com/report/index/bp-9f2cb221-f5e3-4618-a38b-b3fb32091105 - http://crash-stats.mozilla.com/report/index/d5d60e99-e554-47c9-a1ee-495102091104?p=1 Reproducible: Couldn't Reproduce Theme: Red Cats (green flavor) - version 4.2.4 Add-ons (version): - FlashGot (1.2.0.7) - Greasemonkey (0.8.20090920.2) - IE Tab (1.5.20090525) - Java Quick Starter (1.0) - Microsoft .NET Framework Assistant (1.1) - Move Media Player (1.0.0.07133000006) - PC Sync 2 Synchronization Extension (1.0.0.713) - Currently disabled - Phoenix (1.6.0) - Recently installed - currently disabled - Reload Plus (1.0) - Currently disabled - Restart Firefox (0.3) - WOT (20090918) - Currently disabled - Xmarks (3.3.3)
Comment 1•15 years ago
|
||
bp-18197741-f6af-4faa-9ceb-d88562091105 : no stack bp-9f2cb221-f5e3-4618-a38b-b3fb32091105 : flash plugin crash bp-9f2cb221-f5e3-4618-a38b-b3fb32091105 : flash plugin crash bp-d5d60e99-e554-47c9-a1ee-495102091104 : crash in @free , looks like broken stack
The last crash yesterday might give an indication of a memory leak... After I restarted Firefox and restored all tabs, the Virtual Memory usage was about 550 MB. Right as it was crashing, Firefox froze and the CPU went up to about 50% for Firefox. The Virtual Memory consumption at that point was about 1.6 GB. Unfortunately, your system did not accept the Crash Report (throttling). Hopefully it'll accept the next one. I want to mention that this also seems to affect Firefox 1.6 Beta 1. I installed that yesterday, and also installed the piece of software that disables Add-on compatibility checking, so I'm using all the same add-ons on 1.6 Beta 1 as I mentioned above.
Another crash in version 3.5.4 (went back to this one after 3.6.0 Beta 1 shows the exact same problem)... I did not observe it as it crashed while I was working in another application. It did however increase the memory usage while browsing, and I would guess that it crashed with a Virtual Memory usage of about 1.4 - 1.6 GB. Crash Report: - http://crash-stats.mozilla.com/report/index/c302046c-d4d3-41ee-8f50-6e4ba2091106
Comment 4•15 years ago
|
||
bp-c302046c-d4d3-41ee-8f50-6e4ba2091106 : crash @free , looks like broken stack
Upgraded to 3.5.5. Problem seems to be identical on this version. Left the computer on, but locked, for more than 24 hours. When I returned to the computer Firefox had crashed - without starting the Crash Reporter.
I have observed that when it crashes without starting the Crash Reporter, it actually crashes with a C++ Runtime Error (separate dialog box).
Another crash report (after upgrading to Firefox 3.5.5): http://crash-stats.mozilla.com/report/index/3879f6cd-3090-4ed2-851a-7c7052091108
Tried WinDbg, but am not too familiar with the tool... Please let me know if there are any things I can do to improve the output. I ran "kp" and "!analyze" several times along the way, but I believe the last one might be the most significant one... Kept on typing F5 (Go) after each exception, to proceed running Firefox. After the last one, it would no longer give me back control of the application, so I eventually stopped debugging.
Attachment #411412 -
Attachment mime type: application/octet-stream → text/plain
Comment 10•15 years ago
|
||
good enough for starters. Tue Nov 10 13:25:18.609 2009 (GMT+1): ModLoad: 03080000 030d3000 C:\Documents and Settings\oyrous\Application Data\Mozilla\Firefox\Profiles\lpk2qjna.default\extensions\{77b819fa-95ad-4f2c-ac7c-486b356188a9}\plugins\npietab.dll Tue Nov 10 13:25:18.625 2009 (GMT+1): ModLoad: 7df70000 7df92000 C:\WINDOWS\system32\oledlg.dll Tue Nov 10 13:25:18.640 2009 (GMT+1): (1984.2080): Access violation - code c0000005 (first chance) First chance exceptions are reported before any exception handling. This exception may be expected and handled. eax=00000000 ebx=030d0901 ecx=0012d4ac edx=0012d4b4 esi=0012d434 edi=00000001 eip=030d0917 esp=0012d41c ebp=0012d440 iopl=0 nv up ei pl zr na pe nc cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000 efl=00010246 *** ERROR: Symbol file could not be found. Defaulted to export symbols for C:\Documents and Settings\oyrous\Application Data\Mozilla\Firefox\Profiles\lpk2qjna.default\extensions\{77b819fa-95ad-4f2c-ac7c-486b356188a9}\plugins\npietab.dll - npietab!NP_GetEntryPoints+0x4d583: 030d0917 8908 mov dword ptr [eax],ecx ds:0023:00000000=???????? So, npietab crashed once, this was a first chance exception and something handled it. Personally, I'd suggest not using ietab. I really don't want to support it, so for any future logs, please be sure you disable that extension. sorry. Tue Nov 10 13:25:56.562 2009 (GMT+1): (24cc.2628): Break instruction exception - code 80000003 (first chance) very odd. those generally shouldn't exist in release code (The Guard Page violations are typically flash iirc) eax=00000000 ebx=00000000 ecx=7c800000 edx=77c61ae8 esi=7c90de6e edi=00000000 eip=7c90e514 esp=0012fdc8 ebp=0012fec4 iopl=0 nv up ei pl zr na pe nc cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000 efl=00000246 ntdll!KiFastSystemCallRet: 7c90e514 c3 ret 1:031> g That's a process dying. Our process is 0:xxx> Sorry, that instructions are designed to support multiple processes but only barely. After this set of comments I think someone will probably update them to explain a bit more about them. Tue Nov 10 15:22:14.056 2009 (GMT+1): (1984.2080): C++ EH exception - code e06d7363 (first chance) Tue Nov 10 15:22:14.056 2009 (GMT+1): (1984.2080): C++ EH exception - code e06d7363 (!!! second chance !!!) eax=0012b898 ebx=29db4104 ecx=00000000 edx=781d8ba8 esi=0012b920 edi=0012b9c0 eip=7c812afb esp=0012b894 ebp=0012b8e8 iopl=0 nv up ei pl nz na pe nc cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000 efl=00200206 kernel32!RaiseException+0x53: 7c812afb 5e pop esi Missing image name, possible paged-out or corrupt data. Missing image name, possible paged-out or corrupt data. 0:000> kp ChildEBP RetAddr 0012b8e8 7815d2ab kernel32!RaiseException+0x53 0012b920 78165c93 MOZCRT19!_CxxThrowException(void * pExceptionObject = 0x0012b930, struct _s__ThrowInfo * pThrowInfo = 0x781cba44)+0x46 [f:\sp\vctools\crt_bld\self_x86\crt\prebuild\eh\throw.cpp @ 161] 0012b938 1000f977 MOZCRT19!operator new(unsigned int size = <Memory access error>)+0x73 [e:\builds\moz2_slave\win32_build\build\obj-firefox\memory\jemalloc\src\new.cpp @ 61] 0012b944 1000f87e xul!nsDeque::GrowCapacity(void)+0x27 [e:\builds\moz2_slave\win32_build\build\obj-firefox\xpcom\build\nsdeque.cpp @ 182] 0012b998 1016a110 xul!GraphWalker::DoWalk(class nsDeque * aQueue = 0x29da016c)+0x21e [e:\builds\moz2_slave\win32_build\build\xpcom\base\nscyclecollector.cpp @ 1222] 0012b9f0 1016a1d3 xul!GraphWalker::WalkFromRoots(struct GCGraph * aGraph = 0x0012bb14)+0xb0 [e:\builds\moz2_slave\win32_build\build\xpcom\base\nscyclecollector.cpp @ 1207] 0012ba58 1017d0dc xul!nsCycleCollector::BeginCollection(void)+0x74 [e:\builds\moz2_slave\win32_build\build\xpcom\base\nscyclecollector.cpp @ 2526] 0012ba68 004eb13e xul!XPCCycleCollectGCCallback(struct JSContext * cx = 0x00535bfc, JSGCStatus status = 11035648 (No matching enumerant))+0x3b [e:\builds\moz2_slave\win32_build\build\js\src\xpconnect\src\nsxpconnect.cpp @ 390] 0012bb14 00535bfc js3250!js_GC(struct JSContext * cx = 0x00a86400, JSGCInvocationKind gckind = GC_NORMAL (0))+0x28e [e:\builds\moz2_slave\win32_build\build\js\src\jsgc.cpp @ 3500] 0012bb28 101953dd js3250!JS_GC(struct JSContext * cx = 0x00000000)+0x4c [e:\builds\moz2_slave\win32_build\build\js\src\jsapi.cpp @ 2458] 0012bbe4 10183b93 xul!nsXPConnect::Collect(void)+0x74 [e:\builds\moz2_slave\win32_build\build\js\src\xpconnect\src\nsxpconnect.cpp @ 478] 0012fa94 101d9b10 xul!nsCycleCollector::Collect(unsigned int aTryCollections = 1)+0x87 [e:\builds\moz2_slave\win32_build\build\xpcom\base\nscyclecollector.cpp @ 2386] 0012faa0 101d9ada xul!nsCycleCollector_collect(void)+0x11 [e:\builds\moz2_slave\win32_build\build\xpcom\base\nscyclecollector.cpp @ 3046] 0012faa4 101a2b0b xul!nsJSContext::CC(void)+0x2a [e:\builds\moz2_slave\win32_build\build\dom\src\base\nsjsenvironment.cpp @ 3512] 0012faac 100da440 xul!GCTimerFired(class nsITimer * aTimer = 0x100934ee, void * aClosure = 0x05992f90)+0x35 [e:\builds\moz2_slave\win32_build\build\dom\src\base\nsjsenvironment.cpp @ 3625] 0012fac0 100da3b1 xul!nsTimerImpl::Fire(void)+0x80 [e:\builds\moz2_slave\win32_build\build\xpcom\threads\nstimerimpl.cpp @ 420] 0012facc 100934ee xul!nsTimerEvent::Run(void)+0x1f [e:\builds\moz2_slave\win32_build\build\xpcom\threads\nstimerimpl.cpp @ 514] 0012faf0 1012a6a8 xul!nsThread::ProcessNextEvent(int mayWait = <Memory access error>, int * result = <Memory access error>)+0x1be [e:\builds\moz2_slave\win32_build\build\xpcom\threads\nsthread.cpp @ 522] 0012fb04 1012a86f xul!NS_ProcessNextEvent_P(class nsIThread * thread = 0x00000000, int mayWait = 1021483)+0x20 [e:\builds\moz2_slave\win32_build\build\obj-firefox\xpcom\build\nsthreadutils.cpp @ 236] 0012fb30 1020f2bc xul!nsThread::Shutdown(void)+0xa4 [e:\builds\moz2_slave\win32_build\build\xpcom\threads\nsthread.cpp @ 468] 0:000> !analyze -v -f That's the actual crash. Sadly, it's in code I own, and basically it means "you <reporter> ran out of memory and I <timeless> never fixed this code to deal with it" - sorry. 0:000> g WARNING: Continuing a non-continuable exception We need to add instructions saying "stop at second chance exceptions and definitely don't continue going once you reach that message". Anyway, I'd like to say that you did a good job following our instructions, thanks :). And sorry about the crash. I have an incomplete patch floating around somewhere for this, but it's mostly a pain. A more useful description: state: you're low on memory. task: periodic garbage collection steps: . a dom window asks the cycle collector to collect stuff to gc . the collector chains through to javascript and asks it to gc . it in turn talks to the cycle collector which starts walking around looking for things that are still alive process: . it uses my structure to grow a list of living things problem: . my bits (and the callers) don't handle oom, we just throw (and pass) along an exception when this happens. The basic fix is to my code, but fixing that just bubbles the problem out one layer, i didn't finish fixing that layer. There's a bug somewhere with this (not necessarily with this helpful explanation, but hopefully with my unfinished patches) - hence "DUPEME". Probably a more interesting question is why you're running out of memory. What extensions are you using? There's a tool to help find leaks in extensions (not really my area)
Component: General → XPCOM
Keywords: crash
Product: Firefox → Core
QA Contact: general → xpcom
Summary: Massive increase in random crashes after upgrade to Firefox 3.5.4 → Massive increase in random crashes after upgrade to Firefox 3.5.4 - OOM [@ _CxxThrowException - operator new - nsDeque::GrowCapacity]
Whiteboard: DUPEME
Version: 3.5 Branch → 1.9.1 Branch
Reporter | ||
Comment 11•15 years ago
|
||
It seems that "something" is leaking memory bad, and it all really started right after I upgraded to Firefox 3.5.4. I added a list of the add-ons I'm running in my very first post... I've added a couple more since then, but here's the current list: - Add-on compatibility Reporter (0.1) - Ancestry.com Advanced Image Viewer (1.0.0.1) - Crash Report Helper (1.1) - FlashGot (1.2.0.7) - Disabled - Greasemonkey (0.8.20090920.2) - No scripts installed - IE Tab (1.5.20090525) - Now disabled, but was enabled until I read your last comment. Will try to run for a while with this disabled - Java Quick Starter (1.0) - Microsoft .NET Framework Assistant (1.1) - Move Media Player (1.0.0.071303000006) - PC Sync 2 Syncrhonization Extension (1.0.0.713) - Disabled - Phoenix (1.6.0) - Disabled - Reload Plus (1.0) - Disabled - Reload Every (3.5.1) - Restart Firefox (0.3) - WOT (20091028) - Disabled - Xmarks (3.3.3)
Reporter | ||
Comment 12•15 years ago
|
||
...and if anyone can direct me to the tool for finding leaks in extensions, I'll give that a shot... Since this startet happening pretty much right after the upgrade to Firefox 3.5.4, I'm not convinced it's an add-on that's causing it.
Reporter | ||
Comment 14•15 years ago
|
||
I disabled IETab and installed the Leak monitor extension. To me, this WinDbg output seems to be more of the same. The leak monitor did not appear to yield much. For every leak it came up with, there seemed to be a release of memory soon after with a second dialog box coming up empty (no remaining leaking processes). Also, I could not see any clear pattern to the leaks, although I'm clearly not very familiar with this extension. A lot of the leaks had no URLs included.
Reporter | ||
Comment 15•15 years ago
|
||
I was paying close attention to the Leak Monitor 0.4.3 this time... I copied the windows that were still open, and had not been explicitly reclaimed with its own separate window, to the clipboard and pasted them into a text file... They are in the sequence they popped up (top to bottom). I've separated each leak window with a few spaces and dashes (should be 10 in all), and I'm not sure if you can make any sense of it - I sure can't... :)
Attachment #411648 -
Attachment mime type: application/octet-stream → text/plain
Comment 16•15 years ago
|
||
Comment on attachment 411648 [details] WinDbg trace - probably more of the same >First chance exceptions are reported before any exception handling. >This exception may be expected and handled. >eax=00000000 ebx=00000000 ecx=00000008 edx=0003ffff esi=0012bba4 edi=028e8af0 >eip=1006413d esp=0012ba88 ebp=0012bbc0 iopl=0 nv up ei pl nz na po nc >cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000 efl=00010202 >xul!NoteJSChild+0x6d: >1006413d 8b4304 mov eax,dword ptr [ebx+4] ds:0023:00000004=???????? >1:002> kp >ChildEBP RetAddr >0012ba94 0051a6f1 xul!NoteJSChild(struct JSTracer * trc = 0x00000000, void * thing = 0x40c0000e, unsigned long kind = 8)+0x6d [e:\builds\moz2_slave\win32_build\build\js\src\xpconnect\src\nsxpconnect.cpp @ 692] >00000000 00000000 js3250!js_TraceObject(struct JSTracer * trc = <Memory access error>, struct JSObject * obj = <Memory access error>)+0x2b1 [e:\builds\moz2_slave\win32_build\build\js\src\jsobj.cpp @ 5805] Well, it isn't the same. We can either change the focus of this bug to that (it seems more exciting and let someone else chase it), or file a new bug.
Comment 17•15 years ago
|
||
Comment on attachment 411655 [details]
Leak Monitor 0.4.3 - Clipboard copies
so you have 6 leaked windows, that's fairly expensive.
Reporter | ||
Comment 18•15 years ago
|
||
I disabled all extensions (add-ons) to see if that would change anything. Fortunately or unfortunately (whichever way you wanna see it) it didn't. The memory loss leak might be smaller, but I'm not certain. In any case, it still appears to be leaking memory bigtime. I did note that the virtual memory usage went up quite a bit (at least 2-300 MB) when playing a Facebook game - Bejeweled - which I'm quite certain is a Flash game. I'm not certain if that matters much, but I thought it was worth noting. It was still leaking memory before and after this, but seemingly leaking faster while this was going on. Attached the WinDbg trace that was generated during this run with all extensions disabled. Have a look at it, and see what you think...
Updated•15 years ago
|
Attachment #412010 -
Attachment mime type: application/octet-stream → text/plain
Comment 19•15 years ago
|
||
the nsDeque problem is bug 464043
Component: XPCOM → XPConnect
QA Contact: xpcom → xpconnect
Summary: Massive increase in random crashes after upgrade to Firefox 3.5.4 - OOM [@ _CxxThrowException - operator new - nsDeque::GrowCapacity] → Massive increase in random crashes after upgrade to Firefox 3.5.4 - OOM? [@ NoteJSChild - js_TraceObject]
Whiteboard: DUPEME
Reporter | ||
Comment 20•15 years ago
|
||
I'm not sure what this refers to. Is that the reason for the crash or the reason for the memory leak?
Comment 21•15 years ago
|
||
5707 js_TraceObject(JSTracer *trc, JSObject *obj) 5718 cx = trc->context; deref trc-> unless cx is optimized away 5776 if (!JS_CLIST_IS_EMPTY(&cx->runtime->watchPointList)) deref cx-> ==> can't be optimized away 5804 JS_SET_TRACING_DETAILS(trc, js_PrintObjectSlotName, obj, i); 5805 JS_CallTracer(trc, JSVAL_TO_TRACEABLE(v), JSVAL_TRACE_KIND(v)); 225 #define IS_GC_MARKING_TRACER(trc) ((trc)->callback == NULL) 2657 JS_CallTracer(JSTracer *trc, void *thing, uint32 kind) 2669 if (!IS_GC_MARKING_TRACER(trc)) { dereferences trc-> again, ==> trc is still not null. 2670 trc->callback(trc, thing, kind); 2671 goto out; 2761 out: 2766 return; /* to avoid out: right_curl when DEBUG is not defined */ this triple (2671, 2761, 2766) forms a tail call optimization point, which is why the frame isn't visible in our stack trace. 670 NoteJSChild(JSTracer *trc, void *thing, uint32 kind) 674 TraversalTracer *tracer = static_cast<TraversalTracer*>(trc); 692 tracer->cb.NoteScriptChild(nsIProgrammingLanguage::JAVASCRIPT, thing); we crash here with trc = 0, dereferencing tracer-> (alias of trc). I don't get it. :(
Comment 22•13 years ago
|
||
xref Bug 490164 Crash [@ NoteJSChild]
Assignee | ||
Updated•13 years ago
|
Crash Signature: [@ NoteJSChild - js_TraceObject]
Reporter | ||
Comment 24•13 years ago
|
||
Hi, Wayne... I'm currently using the latest released version of Firefox (4.0.1) and I am not seeing the problem. I also used all the betas of Firefox 4, and to my recollection, the problem did not occur there either. $Øyvind
Comment 25•13 years ago
|
||
WFM per reporter
Status: UNCONFIRMED → RESOLVED
Closed: 13 years ago
Resolution: --- → WORKSFORME
Whiteboard: [closeme 2011-06-19]
You need to log in
before you can comment on or make changes to this bug.
Description
•