Closed Bug 595635 Opened 14 years ago Closed 13 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: 14 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: 14 years ago → 13 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.