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

Status: RESOLVED WORKSFORME

(Core :: JavaScript Engine, defect)

Description

[Øyvind Yrke]

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:
N/A
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

[Øyvind Yrke]

Attachment: Minidump created by Visual Studio

Comment 2

[Øyvind Yrke]

Attachment: FF plugins as reported by about:plugins

Comment 3

[Tyler Downer [He/Him]]

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.

Comment 4

[Øyvind Yrke]

Attachment: 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?)

Comment 5

[Tyler Downer [He/Him]]

Oh, and update your silverlight:) Timeless should check this.
The new version of plugins could help your mem issues.

Comment 6

[timeless]

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:
js3250!realloc:
                           00352048 

00352000 - js3250!js_json_stringify
                           000064f0 

(js3250!js_json_stringify+0x28dbc)-00352000 
                           000228cc 

FAULTING_IP: 
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

DEFAULT_BUCKET_ID:  NULL_POINTER_READ

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".

EXCEPTION_PARAMETER1:  00000000

EXCEPTION_PARAMETER2:  00000000

READ_ADDRESS:  00000000 

FOLLOWUP_IP: 
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]

FAULTING_THREAD:  00000d5c

PRIMARY_PROBLEM_CLASS:  NULL_POINTER_READ

BUGCHECK_STR:  APPLICATION_FAULT_NULL_POINTER_READ

LAST_CONTROL_TRANSFER:  from 003748cc to 78139cd8

STACK_TEXT:  
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

Comment 7

[Nochum Sossonko [:Natch]]

Dupe of bug 503402?

Comment 8

[Øyvind Yrke]

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

[Øyvind Yrke]

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

[Andreas Gal :gal]

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

Comment 11

[Robert Sayre]

which version of Firefox are you using?

Comment 12

[Øyvind Yrke]

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.

Comment 13

[Daniel Veditz [:dveditz]]

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.

Comment 14

[Øyvind Yrke]

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).

Comment 15

[Tyler Downer [He/Him]]

Reporter, do you still see this crash with Firefox 4?

Comment 16

[Øyvind Yrke]

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

[Josh Aas]

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?