Random crashes while browsing (JIT?) [@ free ]




9 years ago
3 years ago


(Reporter: spirou_no, Unassigned)



1.9.1 Branch
Windows XP

Firefox Tracking Flags

(status1.9.1 ?)


(Whiteboard: [sg:needinfo] dupe of bug 503402?, crash signature)


(3 attachments)



9 years ago
User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1) Gecko/20090624 Firefox/3.5
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1) Gecko/20090624 Firefox/3.5

FF3.5 crashes randomly, but rarely (once every few days).

The crash is caused by a null pointer referenced in mozcrt19.dll.

I will attach a minidump created by Visual Studio when I have finished writing this report.

Reproducible: Sometimes

Steps to Reproduce:
Actual Results:  
FF3.5 crashes

Expected Results:  
It should not crash

In my session I have 4-5 windows with more than 100 tabs.  The crash occurs only every few days, I can not relate it to a particular webpage.  Also, I don't see any other ill effects (other reports says lost bookmarks or similar).  In short FF reopens were it was.

Note the builtin "Mozilla Crash Reporter" does not appear, FF just dies.  Instead I get the popup "Do you want to debug ... with Visual Studio", which I did and created the dump file.

Also, "about:crashes" reports no crashes.

Comment 1

9 years ago
Created attachment 387721 [details]
Minidump created by Visual Studio

Comment 2

9 years ago
Created attachment 387722 [details]
FF plugins as reported by about:plugins
Can you get a stacktrace using windbg? https://developer.mozilla.org/En/How_to_get_a_stacktrace_for_a_bug_report
Also, update your flash, quicktime, Java, and any other plugins to the latest, and try to reproduce in Firefox safe mode.
Keywords: crash
Version: unspecified → 3.5 Branch

Comment 4

9 years ago
Created attachment 387760 [details]
Stacktrace with symbols resolved (from minidump)

When reopening Firefox with all previous tabs, memory usage reported by Sysinternals process explorer is 332MB private bytes, 586MB virtual size.

I'll keep an eye on these (is it as simple as FF running out of memory?)
Oh, and update your silverlight:) Timeless should check this.
The new version of plugins could help your mem issues.

Comment 6

9 years ago
So, js_json_stringify is tiny, i'm pretty sure it's at the end of spidermonkey and what we're seeing is JIT'd code.

the end of the world seems to be near:

00352000 - js3250!js_json_stringify


mozcrt19!free+18 [e:\builds\moz2_slave\win32_build\build\obj-firefox\memory\jemalloc\src\jemalloc.c @ 6404]
78139cd8 8b07            mov     eax,dword ptr [edi]

EXCEPTION_RECORD:  ffffffff -- (.exr 0xffffffffffffffff)
.exr 0xffffffffffffffff
ExceptionAddress: 78139cd8 (mozcrt19!free+0x00000018)
   ExceptionCode: c0000005 (Access violation)
  ExceptionFlags: 00000000
NumberParameters: 2
   Parameter[0]: 00000000
   Parameter[1]: 00000000
Attempt to read from address 00000000


PROCESS_NAME:  firefox.exe

ERROR_CODE: (NTSTATUS) 0xc0000005 - The instruction at "0x%08lx" referenced memory at "0x%08lx". The memory could not be "%s".

EXCEPTION_CODE: (NTSTATUS) 0xc0000005 - The instruction at "0x%08lx" referenced memory at "0x%08lx". The memory could not be "%s".



READ_ADDRESS:  00000000 

mozcrt19!free+18 [e:\builds\moz2_slave\win32_build\build\obj-firefox\memory\jemalloc\src\jemalloc.c @ 6404]
78139cd8 8b07            mov     eax,dword ptr [edi]




LAST_CONTROL_TRANSFER:  from 003748cc to 78139cd8

0012f694 003748cc 00000001 008d5000 1eed7b64 mozcrt19!free+0x18 [e:\builds\moz2_slave\win32_build\build\obj-firefox\memory\jemalloc\src\jemalloc.c @ 6404]
0012f6ec 00325245 008d5000 00000001 1eed7b64 js3250!js_json_stringify+0x28dbc
0012f87c 0032cee7 008d5000 1d4a3f80 008d5000 js3250!js_Interpret+0x1825 [e:\builds\moz2_slave\win32_build\build\js\src\jsinterp.cpp @ 5147]
0012f928 1005571f 008d5000 00000003 1d4a3f80 js3250!js_Invoke+0x447 [e:\builds\moz2_slave\win32_build\build\js\src\jsinterp.cpp @ 1394]
0012fb4c 10047048 009848b0 26ad30c0 00000003 xul!nsXPCWrappedJSClass::CallMethod+0x5ef [e:\builds\moz2_slave\win32_build\build\js\src\xpconnect\src\xpcwrappedjsclass.cpp @ 1698]
0012fb64 1020c307 26ad30c0 00000003 00a34280 xul!nsXPCWrappedJS::CallMethod+0x38 [e:\builds\moz2_slave\win32_build\build\js\src\xpconnect\src\xpcwrappedjs.cpp @ 562]
0012fc18 1020c36e 2614ea00 00000003 0012fc40 xul!PrepareAndDispatch+0xe7 [e:\builds\moz2_slave\win32_build\build\xpcom\reflect\xptcall\src\md\win32\xptcstubs.cpp @ 114]
0012fc34 100d9566 2614ea00 26846dc0 108a10b4 xul!SharedStub+0x16 [e:\builds\moz2_slave\win32_build\build\xpcom\reflect\xptcall\src\md\win32\xptcstubs.cpp @ 142]
0012fc50 100d93d7 0081e490 00000000 10042283 xul!nsTimerImpl::Fire+0x176 [e:\builds\moz2_slave\win32_build\build\xpcom\threads\nstimerimpl.cpp @ 429]
0012fc5c 10042283 26236c00 0081e470 0012ff40 xul!nsTimerEvent::Run+0x1f [e:\builds\moz2_slave\win32_build\build\xpcom\threads\nstimerimpl.cpp @ 514]
0012fc88 1002e3fa 00000001 00000001 0012fca8 xul!nsThread::ProcessNextEvent+0x253 [e:\builds\moz2_slave\win32_build\build\xpcom\threads\nsthread.cpp @ 511]
0012fca0 101c9903 00000001 004ebb00 10100fb0 xul!nsBaseAppShell::Run+0x4a [e:\builds\moz2_slave\win32_build\build\widget\src\xpwidgets\nsbaseappshell.cpp @ 169]
0012fcac 10100fb0 0090a130 0081f0a0 00000000 xul!nsAppStartup::Run+0x1e [e:\builds\moz2_slave\win32_build\build\toolkit\components\startup\src\nsappstartup.cpp @ 194]
0012fcb4 0081f0a0 00000000 0081f098 00816280 xul!XRE_main+0xe2a [e:\builds\moz2_slave\win32_build\build\toolkit\xre\nsapprunner.cpp @ 3300]
WARNING: Frame IP not in any known module. Following frames may be wrong.
0012fcb8 00000000 0081f098 00816280 00816280 0x81f0a0
Assignee: nobody → general
Component: General → JavaScript Engine
Product: Firefox → Core
QA Contact: general → general
Summary: Random crashes while browsing (with minidump) → Random crashes while browsing (JIT?) [@ free ]
Version: 3.5 Branch → 1.9.1 Branch
Attachment #387760 - Attachment mime type: application/octet-stream → text/plain
Dupe of bug 503402?
Group: core-security
Keywords: testcase-wanted
Whiteboard: [sg:investigate] dupe of bug 503402?

Comment 8

9 years ago
Hi, I've got another crash.  It appears to be out of memory (I have the dump, but only one element in the callstack).  Looks like the sinner is the yahoo mail client.  Not sure if this issue then belongs to firefox or to yahoo

How to repro.
1. use a memory watch tool, e.g. sysinternal procexp and watch private bytes and virtual size for firefox.
2. login to a yahoo account with many messages
3. browse quicky in the inbox (i.e. press the up/down keys without waiting for the messages to appear).
4. watch the memory usage whilst pressing up/down.  I managed to get firefox to run out of memory even in a clean session (i.e. no other tabs open).

Depending on how many windows/tabs are open, ff will crash sooner rather than later.

Comment 9

9 years ago
Let me add that in step 3, memory usage will increase depending on the number of messages skipped/browsed, but then drop back to normal after some time (a few seconds to 10s of seconds).  However if the peak memory usage (or virtual size) exceeds 2GB, ff will crash.

E.g. even opening the bugzilla message will temporarily increase memory usage 50-100MB.  I have 166 messages in my inbox.

Comment 10

9 years ago
No jit involved here I think. But looks like a json issues. Cc'ing the master of that domain.

Comment 11

9 years ago
which version of Firefox are you using?

Comment 12

9 years ago
I have updated to 3.5.1. The crash is still there (when keeping up/down keys pressed in yahoo mail client).  When I reported the crash, I used 3.5.
status1.9.1: --- → ?
What about the original crash? If it's a duplicate of bug 503402 (a guess based on the stack) it should have gone away in 3.5.1

The Yahoo mail OOM crash should get a separate bug to avoid confusion, unless the stack of those crashes looks the same as your earlier "random" crashes.
Whiteboard: [sg:investigate] dupe of bug 503402? → [sg:needinfo] dupe of bug 503402?

Comment 14

9 years ago
Hi, as the yahoo mail client callstack is different from the one reported here, I have submitted a new Bug 506771.  Some more details added (e.g. much harder to crash 3.5.1 than 3.5).
Reporter, do you still see this crash with Firefox 4?
Crash Signature: [@ free ]

Comment 16

7 years ago
Hard to answer that question, FF4 is history for me now.  I am using FF6 on all my PCs.  I recall robustness improved in 3.6 and 3.7, but I could still crash FF if I tried hard to do so.  cheers.

Comment 17

7 years ago
Apparently the reporter doesn't have an issue any more and the bugs this might be a dupe of have been fixed. I don't see a remaining security issue here.

Can we open this up?
Group: core-security


6 years ago
Last Resolved: 6 years ago
Resolution: --- → WORKSFORME
Keywords: testcase-wanted
You need to log in before you can comment on or make changes to this bug.