Closed Bug 595635 Opened 13 years ago Closed 12 years ago

crash in [@ js::Invoke(JSContext*, js::CallArgs const&, unsigned int) ] or [@ js::Invoke(JSContext*, js::CallArgs const&, unsigned long) ]

Categories

(Core :: JavaScript Engine, defect)

Product:
Core
Component:
JavaScript Engine
Platform:
x86
Windows XP
Type:
defect
Priority:
Not set
Severity:
critical

Tracking

()

Status:
RESOLVED WORKSFORME
Tracking Flags:
Tracking Status
firefox6 - ---
blocking2.0 --- -

People

(Reporter: baffclan, Unassigned)

References

Details

(Keywords: crash, Whiteboard: [need update from crashkill on tracking 6][js-triage-needed])

Crash Data

crash in [@ js::Invoke(JSContext*, js::CallArgs const&, unsigned int) ]

Firefox/20100911031347-trunk/WinXP

bp-ffc9a70c-9d38-4d9e-b6a0-cf3132100912

I think related to bug 595351


Frame 	Module 	Signature [Expand] 	Source
0 		@0x32212c2 	
1 	xul.dll 	js::Invoke 	js/src/jsinterp.cpp:614
2 	xul.dll 	js::ExternalInvoke 	js/src/jsinterp.cpp:644
3 	xul.dll 	nsJSContext::CallEventHandler 	dom/base/nsJSEnvironment.cpp:2186
4 	xul.dll 	nsJSEventListener::HandleEvent 	dom/src/events/nsJSEventListener.cpp:228
5 	xul.dll 	nsEventListenerManager::HandleEventSubType 	content/events/src/nsEventListenerManager.cpp:1112
6 	xul.dll 	nsEventListenerManager::HandleEventInternal 	content/events/src/nsEventListenerManager.cpp:1208
7 	xul.dll 	nsEventTargetChainItem::HandleEventTargetChain 	content/events/src/nsEventDispatcher.cpp:341
8 	mozcrt19.dll 	arena_dalloc_small 	obj-firefox/memory/jemalloc/crtsrc/jemalloc.c:4153
Sorry...
Firefox/20100912031524-trunk/WinXP
Keywords: crash
blocking2.0: --- → ?
#1 topcrash on the trunk.  we should try to get this fixed before b7.
Since 20100915 build, the crash signature has changed :
js::Invoke(JSContext*, js::CallArgs const&, unsigned long) instead of 
js::Invoke(JSContext*, js::CallArgs const&, unsigned int)
Summary: crash in [@ js::Invoke(JSContext*, js::CallArgs const&, unsigned int) ] → crash in [@ js::Invoke(JSContext*, js::CallArgs const&, unsigned int) ] or [@ js::Invoke(JSContext*, js::CallArgs const&, unsigned long) ]
this should probably get some attention before we ship b7.

looks like a start up crash.

combined the two signatures had over 100 crashes yesterday, which would keep it ranked around #4 top crash on trunk.

signature list
  61 js::Invoke(JSContext*, js::CallArgs const&, unsigned long)
  49 js::Invoke(JSContext*, js::CallArgs const&, unsigned int)

Correlation to startup or time of session
110 total crashes for js::Invoke.JSContext...js::CallArgs.const...unsigned.. on 20100916-crashdata.csv
88 startup crashes inside 30 sec.
100 startup crashes inside 3 min.
54 repeated crashes inside 3 min. of last crash

It looks like it was around in b4 and b5, but its a volume regression on mozillla-central.

checking --- js::Invoke.JSContext...js::CallArgs.const...unsigned.. 20100916-crashdata.csv
found in: 4.0b7pre 4.0b6pre 4.0b6 4.0b5 4.0b4
release total-crashes
              js::Invoke.JSContext...js::CallArgs.const...unsigned.. crashes
                         pct.
all     313788  110     0.000350555
4.0b7pr 2954    73      0.0247123
4.0b6pr 649     27      0.0416025
4.0b6   14139   7       0.000495085
4.0b5   22873   2       8.74393e-05
4.0b4   3192    1       0.000313283

os breakdown
js::Invoke.JSContext...js::CallArgs.const...unsigned..Total 110
Win5.1  0.90
Win6.0  0.01
Win6.1  0.07

aboutSessionRestore.xhtml and  aboutHome.xhtml  make up the bulk of the urls.
most of these are family 6, model 6-11, but there are a few family 15, model 1-124

  33 CPU|x86|AuthenticAMD family 6 model 8 stepping 1|1
  22 CPU|x86|AuthenticAMD family 6 model 10 stepping 0|1
  16 CPU|x86|GenuineIntel family 6 model 8 stepping 10|1
   8 CPU|x86|CentaurHauls family 6 model 9 stepping 10|1
   8 CPU|x86|AuthenticAMD family 6 model 6 stepping 2|1
   7 CPU|x86|AuthenticAMD family 6 model 7 stepping 1|1
   3 CPU|x86|GenuineIntel family 6 model 11 stepping 4|1
   2 CPU|x86|GenuineIntel family 6 model 8 stepping 3|1
   2 CPU|x86|GenuineIntel family 6 model 11 stepping 1|1
   2 CPU|x86|CentaurHauls family 6 model 7 stepping 1|1
   1 CPU|x86|GenuineIntel family 6 model 22 stepping 1|1
...
   2 CPU|x86|GenuineIntel family 15 model 2 stepping 9|1
http://crash-stats.mozilla.com/report/index/4da26c44-9391-4852-9c57-9cfa82100916
CPU|x86|GenuineIntel family 15 model 2 stepping 9|1

   1 CPU|x86|GenuineIntel family 15 model 4 stepping 9|1
http://crash-stats.mozilla.com/report/index/1a296766-94d4-41f5-a547-e87c62100916
CPU|x86|GenuineIntel family 15 model 4 stepping 9|1

   1 CPU|x86|GenuineIntel family 15 model 4 stepping 1|1
http://crash-stats.mozilla.com/report/index/e39b4395-27db-489c-ab31-e23632100916
CPU|x86|GenuineIntel family 15 model 4 stepping 1|1

   1 CPU|x86|GenuineIntel family 15 model 1 stepping 3|1
http://crash-stats.mozilla.com/report/index/76e41d6e-2ea5-4d93-b53a-8a6132100916
CPU|x86|GenuineIntel family 15 model 1 stepping 3|1

   1 CPU|x86|AuthenticAMD family 15 model 124 stepping 2|1
http://crash-stats.mozilla.com/report/index/24fbdd4a-8a6b-4f88-b517-e042f2100916
CPU|x86|AuthenticAMD family 15 model 124 stepping 2|1
Depends on: 596457
need to watch to see if the fix for bug 596457 also knocks out these family 15 crashes
WFM on Firefox/20100919031812-trunk/WinXP
Status: NEW → RESOLVED
blocking2.0: ? → beta7+
Closed: 13 years ago
Resolution: --- → FIXED
Crashes are still there.
It is #34 top crasher in b7pre build for the last week.

More reports at:
http://crash-stats.mozilla.com/report/list?range_value=2&range_unit=weeks&signature=js%3A%3AInvoke%28JSContext*%2C%20js%3A%3ACallArgs%20const%26%2C%20unsigned%20long%29&version=Firefox%3A4.0b7pre
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
These crashes seem to have become much less common starting with the 9/29 build.
blocking2.0: beta7+ → beta8+
These are down to 1-2 per day. Recommend moving back to betaN+ or later.
blocking2.0: beta8+ → ?
blocking2.0: ? → betaN+
This is pretty low-volume now, and it looks like at least 2 distinct bugs. Please renom if it becomes common again.
blocking2.0: betaN+ → -
(In reply to comment #12)
> https://crash-stats.mozilla.com/report/index/3c940291-76c9-483b-b1dd-1c32c2110421
> 
> http://cubicvr.org/CubicVR.js/bd3/BeatDetektor3HD.html -> play -> I used the
> time slider -> crash

Thanks! I looked into this and it seems to be some sort of Ogg crash. I filed bug 652006 on it. I got a totally different stack trace for it than the ones in the crash reports here, so I think we might want to keep this bug open.
Whiteboard: nominated in comment 14
could be same as a few of the (js)/(possible pgo) regression bugs that we are tracking.

volume on 5 started to increase just after may 10, then just recently the 5.0 volume started to exceed the 4.0.1 volume

         js::Invoke.JSContext...js::CallArgs.const.,.unsigned.int.
date     total    breakdown by build
         crashes  count build, count build, ...

20110509 81  	60 4.0.12011041322, 
        		6 5.02011042714, 	5 4.02011031805, 
        		3 5.0a22011050804, 	2 5.0a22011050504, 
        		2 4.0b112011020314, 	1 5.0a22011050604, 
        		1 5.0a22011042404, 	1 4.0b42010081813, 
20110510 110  	61 4.0.12011041322, 
        		33 5.02011042714, 	4 4.02011031805, 
        		3 5.0a22011051004, 	3 4.0b112011020314, 
        		1 6.0a12011050203, 	1 5.0a22011050904, 
        		1 5.0a22011050504, 	1 4.0b92011011019, 
        		1 4.0b82010121417, 	1 4.0b102011012116, 
20110511 123  	64 4.0.12011041322, 
        		45 5.02011042714, 	7 4.02011031805, 
        		2 5.0a22011051004, 	2 4.0b112011020314, 
        		1 5.0a22011050804, 	1 4.0b52010083108, 
        		1 4.0b102011012116, 
20110512 130  	79 4.0.12011041322, 
        		39 5.02011042714, 	7 4.02011031805, 
        		2 5.0a22011051104, 	1 6.0a12011041903, 
        		1 4.0b112011020314, 	1 4.0b102011012116, 
...
...
...

20110523 214  	90 4.0.12011041322, 
        		73 5.02011051719, 	29 5.02011042714, 
        		3 5.0a22011052204, 	3 4.0b112011020314, 
        		2 5.0a22011052304, 	2 4.0b92011011019, 
        		2 4.0b82010121417, 	1 6.0a12011042103, 
        		1 6.0a12011041903, 	1 5.0a22011052004, 
        		1 5.0a22011051604, 	1 4.0b72010110414, 
        		1 4.0b62010091408, 	1 4.0b42010081813, 
        		1 4.0b122011022221, 	1 4.02011031805, 
        		1 4.02011030319, 
20110524 229  	100 5.02011051719, 
        		87 4.0.12011041322, 	26 5.02011042714, 
        		3 4.02011031805, 	2 5.0a22011052404, 
        		2 4.0b112011020314, 	1 6.0a12011050103, 
        		1 5.0a22011052104, 	1 5.0a22011052004, 
        		1 5.0a22011051804, 	1 5.0a22011050604, 
        		1 4.2a1pre2011041203, 	1 4.0b62010091408, 
        		1 4.0b42010081714, 	1 4.0b122011022221, 
20110525 321  	177 5.02011051719, 
        		93 4.0.12011041322, 	29 5.02011042714, 
        		7 5.0a22011052404, 	6 4.02011031805, 
        		2 5.0a22011051704, 	2 4.0b112011020314, 
        		1 5.0a22011051004, 	1 4.0b82010121417, 
        		1 4.0b72010110414, 	1 4.0b122011022221, 
        		1 4.0b102011012116,
tracking-firefox6: + → ?
we might want to spin off another bug to cover the significant volume regression on 5.0 and leave this one to cover the smaller underlying residual set of crashes.
I spoke to dmandelin about this. The crashkill team needs to help with some analysis so the JS guys can look at this. Sheila has the next action to come up with some reports to help.
It looks like both this and the js::Interpret signature (and possibly others) don't show up in significant volume for 5.0b3, but EnterMethodJIT is the #1 non-hang signature in 5.0b3 now, so it looks like due to different inlining with or without PGO those crashes seem to shift between EnterMethodJIT (without PGO) and those other signatures..
No need to continue tracking this.
tracking-firefox5: + → ---
Crash Signature: [@ js::Invoke(JSContext*, js::CallArgs const&, unsigned int) ] [@ js::Invoke(JSContext*, js::CallArgs const&, unsigned long) ]
Sheila, is this something we need to continue tracking for Firefox 6?
Crash Signature: [@ js::Invoke(JSContext*, js::CallArgs const&, unsigned int) ] [@ js::Invoke(JSContext*, js::CallArgs const&, unsigned long) ] → [@ js::Invoke(JSContext*, js::CallArgs const&, unsigned int) ] [@ js::Invoke(JSContext*, js::CallArgs const&, unsigned long) ]
Whiteboard: nominated in comment 14 → [need update from crashkill on tracking 6]
Whiteboard: [need update from crashkill on tracking 6] → [need update from crashkill on tracking 6][js-triage-needed]
This has gone way down in the list, as expected since we turned off PGO. I am going to untrack it for now.
tracking-firefox6: + → ---
Ok, I am renominating this for FF6 for us to watch. Not for the PGO issue but because Bob uncovered some interesting data. We need to find out what is going on here so bill is working on it.
tracking-firefox6: --- → ?
Bug 631998 is actually a more specific description of what I was able to reproduce. Hopefully if we fix that, the one in comment 22 will also be covered.
Depends on: 631998
tracking-firefox6: ? → -
Crash Automation can not reproduce with the urls in comment 22 or comment 23.
WFM with Firefox-trunk/WinXP

Mozilla/5.0 (Windows NT 5.1; rv:16.0) Gecko/16.0 Firefox/16.0a1
Status: REOPENED → RESOLVED
Closed: 13 years ago → 12 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.