bugzilla.mozilla.org has resumed normal operation. Attachments prior to 2014 will be unavailable for a few days. This is tracked in Bug 1475801.
Please report any other irregularities here.

Crash in [@ CallPropertyOp ]




JavaScript Engine
8 years ago
7 years ago


(Reporter: GPHemsley, Assigned: Igor Bukanov)


({crash, regression, topcrash})

Mac OS X
crash, regression, topcrash
Dependency tree / graph

Firefox Tracking Flags

(blocking2.0 betaN+)


(Whiteboard: [compartments][hardblocker][firebug-p1], crash signature)



8 years ago
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:

Comment 1

8 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
Maybe this is Firebug related? Can you reproduce without it?

Comment 3

8 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.
(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.

blocking2.0: --- → ?

Comment 5

8 years ago
the signature rose quickly on Friday and over the weekend with crashes mostly on 4.0b8pre build from 2010121003 and later.

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


Comment 6

8 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.


8 years ago
blocking2.0: ? → betaN+


8 years ago
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.

Comment 9

8 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

8 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 

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.
Blocks: 614131, 584237
Whiteboard: [compartments]
If you disable both methodjit and tracejit as of df86d5999fef you get bug 619641.


8 years ago
Assignee: general → adrake
Depends on: 612150
Blocks: 612150
No longer depends on: 612150


8 years ago
Assignee: adrake → igor
Whiteboard: [compartments] → [compartments][hardblocker]
Could thsi be a dup of bug 592202?


Comment 14

8 years ago
We should keep this open and a blocker until we verify if it's fixed by 592202.

Comment 15

8 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

8 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.
Depends on: 592202


8 years ago
Whiteboard: [compartments][hardblocker] → [compartments][hardblocker][firebug-p1]

Comment 17

8 years ago
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.

Comment 19

8 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.

Comment 20

8 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.
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.
Last Resolved: 8 years ago
Resolution: --- → WORKSFORME
Crash Signature: [@ CallPropertyOp ]
You need to log in before you can comment on or make changes to this bug.