Closed
Bug 618549
Opened 14 years ago
Closed 14 years ago
Crash in [@ CallPropertyOp ]
Categories
(Core :: JavaScript Engine, defect)
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
Reporter | ||
Comment 1•14 years ago
|
||
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
Comment 2•14 years ago
|
||
Maybe this is Firebug related? Can you reproduce without it?
Reporter | ||
Comment 3•14 years ago
|
||
(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.
Comment 4•14 years ago
|
||
(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: --- → ?
Comment 5•14 years ago
|
||
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
Comment 6•14 years ago
|
||
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.
Updated•14 years ago
|
blocking2.0: ? → betaN+
Updated•14 years ago
|
blocking2.0: betaN+ → beta9+
Comment 7•14 years ago
|
||
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.
Comment 8•14 years ago
|
||
I can reproduce with your steps using Firebug 1.7X.0a7.
Reporter | ||
Comment 9•14 years ago
|
||
(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.)
Comment 10•14 years ago
|
||
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.
Comment 11•14 years ago
|
||
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.
Blocks: 614131, compartments
Whiteboard: [compartments]
Comment 12•14 years ago
|
||
If you disable both methodjit and tracejit as of df86d5999fef you get bug 619641.
Updated•14 years ago
|
Assignee: general → adrake
Updated•14 years ago
|
Assignee | ||
Updated•14 years ago
|
Assignee: adrake → igor
Updated•14 years ago
|
Whiteboard: [compartments] → [compartments][hardblocker]
Comment 13•14 years ago
|
||
Could thsi be a dup of bug 592202?
/be
Comment 14•14 years ago
|
||
We should keep this open and a blocker until we verify if it's fixed by 592202.
Comment 15•14 years ago
|
||
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+
Comment 16•14 years ago
|
||
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.
Updated•14 years ago
|
Whiteboard: [compartments][hardblocker] → [compartments][hardblocker][firebug-p1]
Comment 17•14 years ago
|
||
It is #1 top crasher on Mac OS X in 4.0b8 for the last week.
Keywords: topcrash
Comment 18•14 years ago
|
||
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.
Reporter | ||
Comment 19•14 years ago
|
||
(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.
Reporter | ||
Comment 20•14 years ago
|
||
(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.
Comment 21•14 years ago
|
||
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.
Updated•14 years ago
|
Status: NEW → RESOLVED
Closed: 14 years ago
Resolution: --- → WORKSFORME
Updated•13 years ago
|
Crash Signature: [@ CallPropertyOp ]
You need to log in
before you can comment on or make changes to this bug.
Description
•