553514 - Crash [@ js_json_stringify]

Status: RESOLVED DUPLICATE of bug 561592

(Core :: JavaScript Engine, defect)

Description

[Justin Dolske [:Dolske]]

User on IRC reported a sporadic crash...

bp-b9ea9adf-eea9-4759-8667-d7d2d2100318

This is currently the #33 topcrash for 3.5.8; I don't see any reports of this for 3.6 though.

Comment 1

[Justin Dolske [:Dolske]]

Mildly interesting that the stack doesn't extend beyond nsTimerEvent::Run. There are not that many JSON.stringify() callers in the tree (assuming it's our code making the call), but I'd idly guess it's Session Store?

Comment 2

[Andreas Gal :gal]

I am sorry that I am being paranoid here again, but JSON.stringify is web-facing, and this report indicates that its possible to make it crash. I will hide the bug. Please feel free to overrule me.

Comment 3

[Brendan Eich [:brendan]]

Hiding this bug just creates dups and hampers data collection. The breakpad link shows a null deref. There's no STR or testcase. Until we have more evidence or an exploitable bug, with some hints to reproduce, this should be open. I will leave it to sayrer to do the deed.

/be

Comment 4

[Andreas Gal :gal]

I am not objecting to opening the bug. I think its a trade-off. I got burned once not closing a bug early on (self-inflicted ...), so I will continue to err on the side of caution. But it does definitely hamper things, and the stack here doesn't look super scary (more DOS than exploitable). Lets leave it to sayrer. Then we have someone to blame if it goes wrong. I can live with that =)

Comment 5

[Robert Sayre]

I am worried it is a GC safety issue, since that is a mistake I made in the past there. I will look into it and reopen if I don't find any problems.

Comment 6

[Jesse Ruderman]

Or you could make this topcrash bug public, and file a new bug in the unlikely event that this bug reports lead you to a GC hazard.

Comment 7

[Robert Sayre]

we're not making this public. there's zero benefit.

Comment 9

[Robert Sayre]

I think we need correlation data for this crash, and the line number of the in json_stringify. Can we deduce that from a raw dump? Breakpad seems to be omitting it.

Comment 10

[chris hofmann]

we might be able to use both of these signatures to dig out more data.

 118 free | js_json_stringify(JSContext*, unsigned int, int*)
   1 js_json_stringify(JSContext*, unsigned int, int*)

Comment 11

[Marcia Knous [:marcia]]

I will look at some of the crash reports and see if there is any commonality to extension that may be present.

Comment 12

[chris hofmann]

update on comment0.  no reports on this in in 3.6.2 or 3.  It definitely looks like we will need 3.5.x to try and reproduce or find correlations to addons.

release total-crashes
              js_json_stringif crashes
                         pct.
all     366784  119     0.000324442
3.5.9   32636   110     0.00337051
3.5.8   2663    8       0.00300413
3.6     18123   1       5.51785e-05

the other thing to try might be to look at code on the stack to spot anything that changed in 3.6 that might have fixed this.

Comment 13

[chris hofmann]

In addition to being 3.5.x it also appears to be 100% windowsXP.

urls look mostly like general browsing

domains of sites
  29 //
  15 http://www.facebook.com
  12 http://apps.facebook.com  onthefarm, inthemafia, cafeworld, scratchchix
  11 \N//
   6 about:blank//
   4 http://www.youtube.com
   4 http://www.nba.com
   3 http://en-us.www.mozilla.com
   2 http://facebook.mafiawars.com

Comment 14

[Andreas Gal :gal]

We might have just fixed this. I will look at the stacks.

Comment 15

[Robert Sayre]

(In reply to comment #14)
> We might have just fixed this. I will look at the stacks.

certainly likely, though none of the stacks have line number information in stringify.

Comment 16

[chris hofmann]

correlation data is back.  there doesnt seem to be and strong individual correlations to anyone module or addon, although there is quite a bit of widespread "extra stuff" scattered in both lists and maybe some kind of combination affect going on.


  free | js_json_stringify(JSContext*, unsigned int, int*)|EXCEPTION_ACCESS_VIOLATION (102 crashes)
     26% (27/102) vs.  16% (4415/28221) {635abd67-4fe9-1b23-4f01-e679fa7484c1} (Yahoo! Toolbar, https://addons.mozilla.org/addon/2032)
     12% (12/102) vs.   1% (283/28221) [e-mail]
     57% (58/102) vs.  46% (13096/28221) {20a82645-c095-46ed-80e3-08825760534b} (Microsoft .NET Framework Assistant, http://www.windowsclient.net/)
     11% (11/102) vs.   3% (841/28221) {7b13ec3e-999a-4b70-b9cb-2617b8323822}
     12% (12/102) vs.   5% (1456/28221) {CAFEEFAC-0016-0000-0014-ABCDEFFEDCBA} (Java Console, http://java.sun.com/javase/downloads/)
      9% (9/102) vs.   3% (764/28221) {B7082FAA-CB62-4872-9106-E42DD88EDE45} (McAfee SiteAdvisor, http://www.siteadvisor.com/)


    10% (10/102) vs.   3% (833/28221) F3HKSTUB.DLL   -- malware
      7% (7/102) vs.   0% (27/28221) YzToolBar.dll     -- possible malware
      7% (7/102) vs.   1% (355/28221) NPMyWebS.dll - Adware.Win32.MyWebSearch.i

Comment 17

[Jesse Ruderman]

Could this be a dup of bug 561592?

Comment 18

[Robert Sayre]

(In reply to comment #17)
> Could this be a dup of bug 561592?

yes

Comment 19

[chris hofmann]

from a sample of all 154 crash reports on 2010 04 26 
on this signature (js_json_stringify JSContext.,.unsigned.int,.int..)  100% of users hitting the crash had addon compat set to [unknown]

Comment 20

[chris hofmann]

to verify watch for the absence of this signature in 3.6.4 and 3.5.8, and also check to make sure this hasn't shown up on trunk.

Comment 21

[chris hofmann]

wonder if crashes  [@ dtoa ] are also related, or are just made visible now by fixes.   a lot of stack passes though the same path.

see

http://crash-stats.mozilla.com/report/index/63117337-a1a5-4f38-a0c4-17dfc2100511

0  	mozjs.dll  	dtoa  	 js/src/dtoa.c:3102
1 	mozjs.dll 	js_dtostr 	js/src/jsdtoa.cpp:124
2 	mozjs.dll 	Str 	js/src/json.cpp:454
3 	mozjs.dll 	JO 	js/src/json.cpp:340
4 	mozjs.dll 	Str 	js/src/json.cpp:472
5 	mozjs.dll 	JO 	js/src/json.cpp:340
6 	mozjs.dll 	Str 	js/src/json.cpp:472
7 	mozjs.dll 	js_Stringify 	js/src/json.cpp:531
8 	mozjs.dll 	js_json_stringify 	js/src/json.cpp:143
9 	mozjs.dll 	js_Interpret 	js/src/jsops.cpp:2199
10 	mozjs.dll 	js_Invoke 	js/src/jsinterp.cpp:831
11 	xul.dll 	nsXPCWrappedJSClass::CallMethod 	js/src/xpconnect/src/xpcwrappedjsclass.cpp:1696
12 	xul.dll 	nsXPCWrappedJS::CallMethod 	js/src/xpconnect/src/xpcwrappedjs.cpp:570
13 	xul.dll 	PrepareAndDispatch 	xpcom/reflect/xptcall/src/md/win32/xptcstubs.cpp:114
14 	xul.dll 	SharedStub 	xpcom/reflect/xptcall/src/md/win32/xptcstubs.cpp:141
15 	nspr4.dll 	nspr4.dll@0xcc0f 	
16 	xul.dll 	nsTimerImpl::Fire 	xpcom/threads/nsTimerImpl.cpp:435
17 	xul.dll 	xul.dll@0x9bba1f 	
18 	nspr4.dll 	_PR_MD_UNLOCK 	nsprpub/pr/src/md/windows/w95cv.c:344
19 	xul.dll 	nsTimerEvent::Run 	xpcom/threads/nsTimerImpl.cpp:519
20 	xul.dll 	nsThread::ProcessNextEvent 	xpcom/threads/nsThread.cpp:527
21 	nspr4.dll 	_PR_MD_UNLOCK 	nsprpub/pr/src/md/windows/w95cv.c:344
22 	xul.dll 	MessageLoop::RunInternal 	ipc/chromium/src/base/message_loop.cc:216
23 	xul.dll 	MessageLoop::RunHandler 	ipc/chromium/src/base/message_loop.cc:199
24 	user32.dll 	UserCallWinProcCheckWow 	
25 	xul.dll 	MessageLoop::Run 	ipc/chromium/src/base/message_loop.cc:173
26 	xul.dll 	nsBaseAppShell::Run 	widget/src/xpwidgets/nsBaseAppShell.cpp:175
27 	xul.dll 	nsAppShell::Run 	widget/src/windows/nsAppShell.cpp:239
28 	xul.dll 	nsAppStartup::Run 	toolkit/components/startup/src/nsAppStartup.cpp:185
29 	xul.dll 	XRE_main 	toolkit/xre/nsAppRunner.cpp:3549
30 	firefox.exe 	wmain 	toolkit/xre/nsWindowsWMain.cpp:120
31 	firefox.exe 	__tmainCRTStartup 	obj-firefox/memory/jemalloc/crtsrc/crtexe.c:591
32 	kernel32.dll 	kernel32.dll@0x13676 	
33 	ntdll.dll 	ntdll.dll@0x39d71 	
34 	ntdll.dll 	ntdll.dll@0x39d44

and bug 563343

Comment 22

[Robert Sayre]

looks like this was indeed a dupe of bug 561592, judging by the crash stats