Closed Bug 618549 Opened 14 years ago Closed 14 years ago

Crash in [@ CallPropertyOp ]

Categories

(Core :: JavaScript Engine, defect)

x86_64
macOS
defect
Not set
blocker

Tracking

()

RESOLVED WORKSFORME
Tracking Status
blocking2.0 --- betaN+

People

(Reporter: GPHemsley, Assigned: igor)

References

Details

(Keywords: crash, regression, topcrash, Whiteboard: [compartments][hardblocker][firebug-p1])

Crash Data

I don't know precisely what's causing this crash, but I do know that it's easily triggered on the latest nightly (build ID: 20101210030339). It appears to be JavaScript-related, but it may also have something to do with cookies. The bug can be triggered just by visiting BMO with a logged-in cookie set. Clearing the cookie logs you out from BMO (obviously), but it also allows you to actually load the page without crashing. Attempting to log in, however, immediately crashes the browser. This may be a dupe, but I don't know enough about this crash to find out. From the crash-stats data, though, it does appear to only affect 64-bit Mac OS X 10.6 builds. Here are my crash reports, which all happened within minutes of each other: bp-4684a081-356a-47e7-bc87-76ccc2101210 bp-41986302-af04-434f-b524-9c0432101210 bp-bc33533e-0d8e-4113-8c0a-74efd2101210 bp-45eef694-1f00-4480-bf6a-5ac682101210 bp-31b89982-8208-4874-9590-6ce2b2101210 bp-244d2b91-e3c3-4302-a148-ae4962101210 bp-3bbf6715-ea4f-4076-bada-d6bc42101210 bp-6b35491e-6996-4d0f-8169-650d52101210
P.S. The crash reports seem to think that this issue is related to bug 540348, which is marked as a dupe of bug 540528, but that was fixed back in February.
Keywords: crash, regression
Maybe this is Firebug related? Can you reproduce without it?
(In reply to comment #2) > Maybe this is Firebug related? Can you reproduce without it? Hmm, you may be right. I reproduced the crash again without changing anything, just to make sure I still could. (That's bp-12be29cf-b56c-4718-9748-1ed1e2101211.) Then I disabled Firebug. (It hanged during the restart, so I had to force quit and restart manually.) But now the same STR (i.e. loading a BMO bug while logged in) does not trigger the crash. For the record (though I'm sure you already know), I also have the Addon Compatibility Reporter installed. Not sure if that affects anything, though, since it's still enabled and the crash hasn't been triggered.
(In reply to comment #2) > Maybe this is Firebug related? Can you reproduce without it? It's caused by Firebug. I can't load bmo/show_bug.cgi unless I have Firebug disabled. Requesting blocking since I presume a lot of people wanting to run a beta will also try to run Firebug. http://crash-stats.mozilla.com/report/list?range_value=2&range_unit=weeks&date=2010-12-12%2011%3A00%3A00&signature=CallPropertyOp&version=Firefox%3A4.0b8pre
blocking2.0: --- → ?
the signature rose quickly on Friday and over the weekend with crashes mostly on 4.0b8pre build from 2010121003 and later. CallPropertyOp date total breakdown by build crashes count build, count build, ... 0101209 10 9 4.0b72010110413, 1 3.6.122010102621, 20101210 35 30 4.0b8pre2010121003, 3 3.6.122010102621, 2 4.0b72010110413, 20101211 19 13 4.0b8pre2010121103, 5 4.0b8pre2010121003, 1 4.0b72010110413, 20101212 24 11 4.0b8pre2010121103, 9 4.0b8pre2010121203, 3 4.0b8pre2010121003, 1 3.6.132010120307, should probably block b8 given involvement with firebug. stack looks like Frame Module Signature [Expand] Source 0 XUL CallPropertyOp js/src/jsfun.cpp:1228 1 XUL js_NativeSet js/src/jscntxtinlines.h:738 2 XUL js_SetPropertyHelper js/src/jsobj.cpp:5609 3 XUL js::mjit::stubs::SetName<0> js/src/methodjit/StubCalls.cpp:260 4 XUL js::mjit::ic::SetProp js/src/methodjit/PolyIC.cpp:1749 5 @0x11b993e9a 6 XUL js::mjit::JaegerShot js/src/methodjit/MethodJIT.cpp:745 7 XUL js::Invoke js/src/jsinterp.cpp:654 8 XUL js_fun_call js/src/jsfun.cpp:2225 9 XUL js::mjit::stubs::UncachedCallHelper js/src/jscntxtinlines.h:684 10 XUL js::mjit::stubs::UncachedCall js/src/methodjit/InvokeHelpers.cpp:441 11 @0x129bead15 12 XUL js::mjit::JaegerShot js/src/methodjit/MethodJIT.cpp:745 13 XUL js::Invoke js/src/jsinterp.cpp:654 14 XUL js_fun_apply js/src/jsfun.cpp:2292 15 XUL js::mjit::stubs::UncachedCallHelper js/src/jscntxtinlines.h:684 16 XUL js::mjit::stubs::UncachedCall js/src/methodjit/InvokeHelpers.cpp:441 17 @0x12b0de52f 18 XUL js::mjit::JaegerShot js/src/methodjit/MethodJIT.cpp:745 19 XUL js::Invoke js/src/jsinterp.cpp:654 20 XUL js_fun_apply js/src/jsfun.cpp:2292 21 XUL js::mjit::stubs::UncachedCallHelper js/src/jscntxtinlines.h:684 22 XUL js::mjit::stubs::UncachedCall js/src/methodjit/InvokeHelpers.cpp:441 23 @0x12b0bed2d 24 XUL js::mjit::JaegerShot js/src/methodjit/MethodJIT.cpp:745 25 XUL js::Invoke js/src/jsinterp.cpp:654 26 XUL js_fun_apply js/src/jsfun.cpp:2292 27 XUL js::mjit::stubs::UncachedCallHelper js/src/jscntxtinlines.h:684 28 XUL js::mjit::stubs::UncachedCall js/src/methodjit/InvokeHelpers.cpp:441 29 @0x12aff63d4 30 XUL js::mjit::JaegerShot js/src/methodjit/MethodJIT.cpp:745 31 XUL js::Invoke js/src/jsinterp.cpp:654 32 XUL js_fun_call js/src/jsfun.cpp:2225 33 XUL js::mjit::stubs::UncachedCallHelper js/src/jscntxtinlines.h:684 34 XUL js::mjit::stubs::UncachedCall js/src/methodjit/InvokeHelpers.cpp:441 35 @0x129bf377f 36 XUL js::mjit::JaegerShot js/src/methodjit/MethodJIT.cpp:745 37 XUL js::Invoke js/src/jsinterp.cpp:654 38 XUL js_fun_apply js/src/jsfun.cpp:2292 39 XUL js::mjit::stubs::UncachedCallHelper js/src/jscntxtinlines.h:684 40 XUL js::mjit::stubs::UncachedCall js/src/methodjit/InvokeHelpers.cpp:441 41 @0x12afe5d4f 42 XUL js::mjit::JaegerShot js/src/methodjit/MethodJIT.cpp:745 43 XUL js::Invoke js/src/jsinterp.cpp:654 44 XUL js_fun_apply js/src/jsfun.cpp:2292 45 XUL js::mjit::stubs::UncachedCallHelper js/src/jscntxtinlines.h:684 46 XUL js::mjit::stubs::UncachedCall js/src/methodjit/InvokeHelpers.cpp:441 47 @0x11b0e1670 48 XUL js::mjit::JaegerShot js/src/methodjit/MethodJIT.cpp:745 49 XUL js::Invoke js/src/jsinterp.cpp:654 50 XUL js::ExternalInvoke js/src/jsinterp.cpp:858 51 XUL JS_CallFunctionValue js/src/jsinterp.h:962 52 XUL nsJSContext::CallEventHandler dom/base/nsJSEnvironment.cpp:2177 53 XUL nsGlobalWindow::RunTimeout dom/base/nsGlobalWindow.cpp:8966 54 XUL nsGlobalWindow::TimerCallback dom/base/nsGlobalWindow.cpp:9311 55 XUL nsTimerImpl::Fire xpcom/threads/nsTimerImpl.cpp:425 56 XUL nsTimerEvent::Run xpcom/threads/nsTimerImpl.cpp:517 57 XUL nsThread::ProcessNextEvent xpcom/threads/nsThread.cpp:626 58 XUL NS_ProcessPendingEvents_P nsThreadUtils.cpp:200 59 XUL nsBaseAppShell::NativeEventCallback widget/src/xpwidgets/nsBaseAppShell.cpp:132 60 XUL nsAppShell::ProcessGeckoEvents widget/src/cocoa/nsAppShell.mm:399 61 CoreFoundation CoreFoundation@0x4e400 62 CoreFoundation CoreFoundation@0x4c5f8 more reports at http://crash-stats.mozilla.com/report/list?signature=CallPropertyOp
Since the reduced test case in comment 2 of Bug 616762 uses eval(), it might be worth checking to see if the setTimeout we see in the older stack frames (53) here may involve eval(), via setTimeout(string) which calls eval to get a function.
blocking2.0: ? → betaN+
blocking2.0: betaN+ → beta9+
Can you give more detailed STR? I just tried and it WFM. That is with a TM nightly of Dec 13, Firebug 1.6X.1b1, logged in to bugzilla.mozilla.org, and load URL https://bugzilla.mozilla.org/show_bug.cgi?id=594054.
I can reproduce with your steps using Firebug 1.7X.0a7.
(In reply to comment #8) > I can reproduce with your steps using Firebug 1.7X.0a7. Yeah, that's the version I'm using. (Or, was, before this crash forced me to disable it.)
Mozilla/5.0 (Windows NT 6.1; rv:2.0b8pre) Gecko/20101214 Firefox/4.0b8pre crashed as soon as I hit the login button on https://bugzilla.mozilla.org/show_bug.cgi?id=618549 When I restarted to see if Firebug panel enable affected the result, I found nothing that would crash. I exited from Firefox 4.0 and started 3.6, then exited and restarted 3.6 (needed to get 3.6 to work again). When I next ran FF4, it crashed (the b.m.o page was in the restore set). I repeated the entire procedure, no crash. So I guess there may be some other variable involved here.
I tried this in a debug build and got a compartment mismatch assertion. adrake says it's possible the underlying cause is the same as 614131. Weirdly: I disabled the methodjit, and it didn't assert or crash. Then I re-enabled it and it was still OK. Sounds like comment 10.
Whiteboard: [compartments]
If you disable both methodjit and tracejit as of df86d5999fef you get bug 619641.
Assignee: general → adrake
Depends on: 612150
Blocks: 612150
No longer depends on: 612150
Assignee: adrake → igor
Whiteboard: [compartments] → [compartments][hardblocker]
Could thsi be a dup of bug 592202? /be
We should keep this open and a blocker until we verify if it's fixed by 592202.
As per today's meeting, beta 9 will be a time-based release. Marking these all betaN+. Please move it back to beta9+ if you believe it MUST be in the next beta (ie: trunk is in an unshippable state without this)
blocking2.0: beta9+ → betaN+
this is a new regression from beta 7 and #19 ranked on beta8 and trunk, so it would be a good one to pick up if a fix becomes available in the next week.
Depends on: 592202
Whiteboard: [compartments][hardblocker] → [compartments][hardblocker][firebug-p1]
It is #1 top crasher on Mac OS X in 4.0b8 for the last week.
Keywords: topcrash
Gordon, can you retest this? We've made a bunch of changes (fixing the suspected underlying bug, eliminating the function CallPropertyOp) that may have fixed this, and will certainly at least change what happens.
(In reply to comment #18) > Gordon, can you retest this? We've made a bunch of changes (fixing the > suspected underlying bug, eliminating the function CallPropertyOp) that may > have fixed this, and will certainly at least change what happens. Interestingly, I am having trouble re-enabling the extension. (I had disabled it due to this bug.) Despite clicking the button and restarting Minefield, the add-ons page does not update, and continues to tell me that restarting Minefield will rectify the issue. (It doesn't.) Obviously, this is a different bug, but it's what I'm facing at the moment. I'll try uninstalling and reinstalling and see if that helps.
(In reply to comment #19) > I'll try uninstalling and > reinstalling and see if that helps. It does seem to help, and there doesn't appear to be any immediate crash from loading BMO. (I'm here, after all.) I don't know if this is a coincidence or not, but my typing seems to be significantly slower now that Firebug is turned on. But that also is out of the scope of this bug.
It looks like the primary issue here is not WFM. (In reply to comment #20) > I don't know if this is a coincidence or not, but my typing seems to be > significantly slower now that Firebug is turned on. But that also is out of the > scope of this bug. There are some bugs on things like this (bug 606461, bug 597627), so you may be seeing one of those. If the problem only occurs with Firebug, then it's probably something else. Feel free to file new bugs on whatever you can find there.
Status: NEW → RESOLVED
Closed: 14 years ago
Resolution: --- → WORKSFORME
Crash Signature: [@ CallPropertyOp ]
You need to log in before you can comment on or make changes to this bug.