Closed Bug 586004 Opened 15 years ago Closed 15 years ago

Crash in [@ js_fun_apply(JSContext*, unsigned int, js::Value*) ] [@ js_fun_apply ] when installing Sync

Categories

(Core :: JavaScript Engine, defect)

Product:
Core
Component:
JavaScript Engine
Type:
defect
Priority:
Not set
Severity:
critical

Tracking

()

Status:
RESOLVED DUPLICATE of bug 592199
Tracking Flags:
Tracking Status
blocking2.0 --- beta7+

People

(Reporter: marcia, Assigned: jorendorff)

References

(
URL
)

Details

(Keywords: crash, regression, topcrash)

Crash Data

Attachments

(3 files)

tehkseven error page unreduced testcase
548.83 KB, application/x-bzip2
Details
Stack trace
99.70 KB, text/plain
Details
Test case: Session Manager session file
68.04 KB, application/octet-stream
Details
Seen while running Mozilla/5.0 (Windows NT 6.1; rv:2.0b4pre) Gecko/20100810 Minefield/4.0b4pre STR: 1. Install Firefox Sync Version 1.4.3 2. Restart the browser. 3. Crash. This shows up in trunk crash stats as the #5 crash. http://tinyurl.com/2g8sztl links to the current crashes on the trunk. Frame Module Signature [Expand] Source 0 mozjs.dll js_fun_apply 1 mozjs.dll js::Interpret js/src/jsinterp.cpp:4713 2 mozjs.dll js::InvokeCommon<int > js/src/jsinterp.cpp:588 3 mozjs.dll js::Invoke js/src/jsinterp.cpp:691 4 mozjs.dll js_fun_apply js/src/jsfun.cpp:2151 5 mozjs.dll js::Interpret js/src/jsinterp.cpp:4713 6 mozjs.dll js::InvokeCommon<int > js/src/jsinterp.cpp:588 7 mozjs.dll js::Invoke js/src/jsinterp.cpp:691 8 mozjs.dll js::InternalInvoke js/src/jsinterp.cpp:754 9 mozjs.dll JS_CallFunctionValue js/src/jsapi.cpp:4836 10 xul.dll nsJSContext::CallEventHandler dom/base/nsJSEnvironment.cpp:2248 11 xul.dll nsGlobalWindow::RunTimeout dom/base/nsGlobalWindow.cpp:8527 12 xul.dll nsGlobalWindow::TimerCallback dom/base/nsGlobalWindow.cpp:8872 13 xul.dll nsTimerImpl::Fire xpcom/threads/nsTimerImpl.cpp:425 14 xul.dll nsTimerEvent::Run xpcom/threads/nsTimerImpl.cpp:517 15 xul.dll nsThread::ProcessNextEvent xpcom/threads/nsThread.cpp:547 16 xul.dll mozilla::ipc::MessagePump::Run ipc/glue/MessagePump.cpp:118 17 xul.dll xul.dll@0xa73cbb 18 xul.dll MessageLoop::RunInternal ipc/chromium/src/base/message_loop.cc:219 19 xul.dll MessageLoop::RunHandler ipc/chromium/src/base/message_loop.cc:202 20 xul.dll _SEH_epilog4 21 xul.dll MessageLoop::Run ipc/chromium/src/base/message_loop.cc:176 22 xul.dll nsBaseAppShell::Run widget/src/xpwidgets/nsBaseAppShell.cpp:175
I will try to hunt down a regression range.
Have been unable to reproduce in the lab using Win Vista, XP and Win 7 despite the fact there are user crash reports with those operating systems. User comments indicate that they were "restarting after downloading a daily update", "just browsing" so it may not be related to Sync.
This is also happening with JS on websites - see the bug I just filed and marked as a dupe of this one.
OS: Windows 7 → All
Hardware: x86 → All
Summary: Crash in [@ js_fun_apply(JSContext*, unsigned int, js::Value*) ] when installing Sync → Crash in [@ js_fun_apply(JSContext*, unsigned int, js::Value*) ] [@ js_fun_apply ] when installing Sync
(In reply to comment #2) > Have been unable to reproduce in the lab using Win Vista, XP and Win 7 despite > the fact there are user crash reports with those operating systems. User > comments indicate that they were "restarting after downloading a daily update", > "just browsing" so it may not be related to Sync. I'm on Win7, and it crashes for me while browsing on some sites, but not on every visit.
Severity: normal → critical
Keywords: regression, regressionwindow-wanted
As Matthew pointed out to me on IRC, the site in the URL from his bug does crash consistently. Will work on a regression range now.
URL: http://mediamemo.allthingsd.com/20100...
(In reply to comment #6) > As Matthew pointed out to me on IRC, the site in the URL from his bug does > crash consistently. Will work on a regression range now. For me it won't crash consistently. However, Tanner and me are trying to get a reduced testcase out of the site.
Regression range: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:2.0b4pre) Gecko/20100807 Minefield/4.0b4pre - Crashes Mozilla/5.0 (Windows NT 6.1; WOW64; rv:2.0b4pre) Gecko/20100806 Minefield/4.0b4pre - Works Pushlog: http://tinyurl.com/323av72
Keywords: regressionwindow-wanted
Fun. Yet another TraceMonkey regression. Here's the narrowed m-c regression range: http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=5aeec895393f&tochange=ddedaa587215 Here the TM regression range: http://hg.mozilla.org/tracemonkey/pushloghtml?fromchange=80df5221d5ac&tochange=c6131ed87e9c Caused by: bug 583262
I might have the wrong TM regression range, as it looks like bug 583262 was backed out and did not reland.
blocking2.0: --- → ?
Assignee: general → jorendorff
blocking2.0: ? → beta4+
On second inspection, the TM regression range is correct. The backout was on only m-c, so the cause is indeed bug 583262.
tvguide.com crashes while loading
Rob: should I assume this isn't really a b4 blocker anymore?
(In reply to comment #14) > Rob: should I assume this isn't really a b4 blocker anymore? Not if it still reproduces.
What's needed to get a fix for this going? Would a stack trace help?
Stack traces are always good. STR and saved (in case the site's content chagnes) testcase, reduced or not, even better. /be
(In reply to comment #18) > Created attachment 466587 [details] > tehkseven error page unreduced testcase I forgot to add this crashes windows but not mac I think.
I have to add that it's a little bit hard to get a reduced testcase: The more I take away from the source to pinpoint the issue, the less often it crashes.
--> beta5+, either way, as per comment 17
blocking2.0: beta4+ → beta5+
Attached file Stack trace —
STR coming up...
STR (Windows 7 x64 REQUIRED): 1. MANDATORY: make sure you have Acrobat Reader 9.x installed 2. Download the attached session file 3. Unzip a recent win32 nightly build of Minefield 4. Create a new profile and launch Minefield 5. Install Session Manager dev build (required for loading the attached session file). Visit this forum and then click the "Public Development Version" link: http://forums.mozillazine.org/viewtopic.php?f=48&t=831545 6. Restart 7. Copy the crash.session file to your <profile_root>\sessions folder 8. Click Tools --> Session Manager --> Load Session... 9. Select the "crash" session and load it, leaving all other settings at default.
This site is also crashing with this error: http://www.squidoo.com/how-to-remove-skin-tags-safely-and-painlessly I do not have Sync set up - not sure if that's tickling this crash or something else.
(In reply to comment #24) > This site is also crashing with this error: > > http://www.squidoo.com/how-to-remove-skin-tags-safely-and-painlessly > > I do not have Sync set up - not sure if that's tickling this crash or something > else. It doesn't crash for me, but the fact that both sites use the Meebo toolbar, this might be an important pointer for the issue being in their code. http://bar.meebo.com/
(In reply to comment #25) > (In reply to comment #24) > > This site is also crashing with this error: > > > > http://www.squidoo.com/how-to-remove-skin-tags-safely-and-painlessly > > > > I do not have Sync set up - not sure if that's tickling this crash or something > > else. > > It doesn't crash for me, but the fact that both sites use the Meebo toolbar, > this might be an important pointer for the issue being in their code. > http://bar.meebo.com/ Still crashes with today's nightly: http://crash-stats.mozilla.com/report/index/38bfc613-8e3e-4ca6-9b29-4bb5a2100818
#2 topcrash in early 4.0b4 data
Still on target for beta5? I have doubts based on the lack of activity! Anything we can do to help diagnose/debug?
Has anyone even attempted my STR?
I just did and was not able to reproduce the crash following your exact instructions. Currently I crash 100% using the site in the URL running Mozilla/5.0 (Windows NT 6.1; WOW64; rv:2.0b5pre) Gecko/20100825 Minefield/4.0b5pre. (In reply to comment #29) > Has anyone even attempted my STR?
Strange. That URL doesn't crash for me.
blocking2.0: beta5+ → beta6+
I got the last crash during regular surfing, nothing to do with Sync
interesting that crowders form of the stack are js_fun_apply. that's the lesser frequent form of the stack. signature list for aug 29 1382 js_fun_apply(JSContext*, unsigned int, js::Value*) 11 js_fun_apply one user mentions having 30-40 tabs open. most active sites for the crash include" 30 http://www.casttv.com/ 26 http://www.usmagazine.com/ 18 http://shaiya.aeriagames.com/misc/ads/sy-us-wideskyscraper.html 11 http://tvnet.sapo.pt/noticias/detalhes.php?id=61005 10 http://www.chia-anime.com/ 10 http://www.casttv.com/shows 10 http://www.casttv.com/online-tv-guide
could be timing related, and thats making it hard to reproduce. a high number of people hit this on http://www.justin.tv seemingly when they get a redirect to/from a page that has been removed to dmca/tos violations. about 15% of the crashes yesterday were like this. 5 http://www.justin.tv/obostontvcom_33ffg/dmca_violation 5 http://www.justin.tv/noataque17/dmca_violation 4 http://pt-br.justin.tv/obostontvcom_33ffg/dmca_violation 3 http://www.justin.tv/mastertv403/dmca_violation 3 http://www.justin.tv/gordonaldo98/dmca_violation 3 http://www.justin.tv/gordonaldo96/dmca_violation 2 http://www.justin.tv/nswtv01m/tos_violation ...long tail snipped
the volume increase for this might starts shortly after to some changes made to some source files on the stack. we were bouncing around at 3-12 crashes per day durning july and early august. then 20100806 16 20100807 18 20100808 57 20100809 62 20100810 134 <continue to run at 70-120 crashes per day durning the rest of august> http://hg.mozilla.org/mozilla-central/annotate/81c119fb86c7/js/src/jsinterp.cpp#l4713 http://hg.mozilla.org/mozilla-central/log/81c119fb86c7/js/src/jsinterp.cpp d695985dc913 2010-08-06 17:19 -0700 Luke Wagner - Bug 585231 - Remove ArgsPrivateNative (r=dmandelin) Frame Module Signature [Expand] Source 0 mozjs.dll js_fun_apply 1 mozjs.dll js::Interpret js/src/jsinterp.cpp:4713 2 mozjs.dll js::InvokeCommon<int > js/src/jsinterp.cpp:588 3 mozjs.dll js::Invoke js/src/jsinterp.cpp:691 4 mozjs.dll js_fun_apply js/src/jsfun.cpp:2151 5 mozjs.dll js::Interpret js/src/jsinterp.cpp:4713 6 mozjs.dll js::InvokeCommon<int > js/src/jsinterp.cpp:588 7 mozjs.dll js::Invoke js/src/jsinterp.cpp:691 8 mozjs.dll js::InternalInvoke js/src/jsinterp.cpp:754 9 mozjs.dll JS_CallFunctionValue js/src/jsapi.cpp:4838 10 xul.dll nsJSContext::CallEventHandler dom/base/nsJSEnvironment.cpp:2248 11 xul.dll nsGlobalWindow::RunTimeout dom/base/nsGlobalWindow.cpp:8527 12 xul.dll nsGlobalWindow::TimerCallback dom/base/nsGlobalWindow.cpp:8872 13 xul.dll nsTimerImpl::Fire xpcom/threads/nsTimerImpl.cpp:425 14 xul.dll nsTimerEvent::Run xpcom/threads/nsTimerImpl.cpp:517 15 xul.dll nsThread::ProcessNextEvent xpcom/threads/nsThread.cpp:547 16 xul.dll mozilla::ipc::MessagePump::Run ipc/glue/MessagePump.cpp:118 17 xul.dll xul.dll@0xa76d9b 18 xul.dll MessageLoop::RunInternal ipc/chromium/src/base/message_loop.cc:219 19 xul.dll MessageLoop::RunHandler ipc/chromium/src/base/message_loop.cc:202 20 mozjs.dll js::ArrayBuffer::freeStorage js/src/jstypedarray.cpp:191 21 xul.dll _SEH_epilog4 22 xul.dll MessageLoop::Run ipc/chromium/src/base/message_loop.cc:176 23 xul.dll nsBaseAppShell::Run widget/src/xpwidgets/nsBaseAppShell.cpp:175
it appears there is an old crash thats been around for a while, but a definite uptick in builds after aug 6. on aug 7th we starting seeing increasing crashes on beta 4pre builds from the morning of the 7th. count stack firefox build 1 js_fun_apply 3.6.3 20100401080539 3 js_fun_apply 3.6.8 20100722155716 2 js_fun_apply 4.0b2 20100720190347 12 js_fun_apply(JSContext*, unsigned int, js::Value*) 4.0b4pre 20100807040603 on aug 8 when we saw the first big pop it was on 4.0b4pre builds from the 7th and 8th. 1 js_fun_apply 3.6.6 20100625231939 4 js_fun_apply 3.6.8 20100722155716 3 js_fun_apply 4.0b2 20100720190347 29 js_fun_apply(JSContext*, unsigned int, js::Value*) 4.0b4pre 20100807040603 20 js_fun_apply(JSContext*, unsigned int, js::Value*) 4.0b4pre 20100808040523 checking --- js_fun_apply 20100808-crashdata.csv found in: 4.0b4pre 3.6.8 4.0b2 3.6.6 release total-crashes js_fun_apply crashes pct. all 258682 57 0.000220348 4.0b4pre2701 49 0.0181414 3.6.8 160700 4 2.48911e-05 4.0b2 12959 3 0.000231499 3.6.6 12996 1 7.69468e-05
The crash reports indicate that the crash is an attempt to load from address 0xa146. The magic value for an Argument object's private-ptr on trace is 0xa126 and (looking at http://hg.mozilla.org/mozilla-central/annotate/9d6448b6a677/js/src/jsinterp.h) offsetof(JSStackFrame, argv) == 0x20, so that seems to be the cause. Before the cset that caused the spike (bug 585231), the private pointer would have pointed to a heap-allocated ArgsPrivateNative struct which had adjacent typemap data, so loads from fp->argv made by the subsequent memcpy in js_fun_apply may or may not have caused crashes, depending on what data was sitting at ArgsPrivateNative + 0x20. One thing I noticed is that, of the 40 or so crash stacks I sampled, all had the same top of stack: 0 js_fun_apply 1 js::Interpret js/src/jsinterp.cpp:4699 2 js::InvokeCommon<int > js/src/jsinterp.cpp:572 3 js::Invoke js/src/jsinterp.cpp:694 4 js_fun_apply js/src/jsfun.cpp:2139 5 js::Interpret js/src/jsinterp.cpp:4699 6 js::InvokeCommon<int > js/src/jsinterp.cpp:572 7 js::Invoke js/src/jsinterp.cpp:694 8 js::InternalInvoke js/src/jsinterp.cpp:734 9 nsJSContext::CallEventHandler dom/base/nsJSEnvironment.cpp:2248 10 nsGlobalWindow::RunTimeout dom/base/nsGlobalWindow.cpp:8553 11 nsGlobalWindow::TimerCallback dom/base/nsGlobalWindow.cpp:8898
(The weird thing is to see that the crash happens exclusively under timeouts, which I wouldn't think was the most common caller of the JS engine.)
It seems like this will be fixed by bug 592199.
Depends on: 592199
If this turns out not to be a duplicate, please reopen. Should be fixed on trunk and beta7.
Status: NEW → RESOLVED
Closed: 15 years ago
Resolution: --- → DUPLICATE
Crash Signature: [@ js_fun_apply(JSContext*, unsigned int, js::Value*) ] [@ js_fun_apply ]
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: