455173 - TM: Crash on Accessing Adblock Plus Preferences

Status: VERIFIED FIXED

(Core :: JavaScript Engine, defect)

Description

[IU]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1b1pre) Gecko/20080913031911 Firefox/2.0.0.16
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1b1pre) Gecko/20080913031911 Firefox/2.0.0.16

Starting with the September 10 nightly build, Adblock Plus now crashes when attempting to access the extension's preferences, if JIT chrome is enabled

Crash does not occur with September 9 nightly and earlier builds.

http://crash-stats.mozilla.com/report/index/320ad8fd-81a9-11dd-8f9b-0013211cbf8a
http://crash-stats.mozilla.com/report/index/1e3ab014-81b7-11dd-aed1-001cc45a2c28
http://crash-stats.mozilla.com/report/index/55fe8e14-81b7-11dd-a636-001cc45a2ce4


Reproducible: Always

Steps to Reproduce:
1. Install Adblock Plus dev build: http://adblockplus.org/devbuilds/
2. Enable JIT chrome and content then restart the browser
3. Click "Cancel" on the Adblock Plus subscription window
4. Right-click the Adblock Plus icon and select "Preferences"
5. Browser crashes

Comment 1

[Nick]

I can confirm it works with the Release Adblock version as well.

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1b1pre) Gecko/20080913150635 Minefield/3.1b1pre ID:20080913150635

Adblock Plus 0.7.5.5

http://crash-stats.mozilla.com/report/index/2a06c202-81d7-11dd-94d3-001cc45a2c28

Comment 2

[Nick]

And of course, by it works, I mean it's broken.  This will cause a crash.

For me, all I have to do is open the Preferences window.

Comment 3

[Matthias Versen [:Matti]]

and it does not crash without jit, right ?

0  	 	@0x3cf5d11  	
1 		@0x67113ff 	
2 	js3250.dll 	js_ExecuteTree 	js/src/jstracer.cpp:2349
3 	js3250.dll 	js_MonitorLoopEdge 	js/src/jstracer.cpp:2502
4 	js3250.dll 	js3250.dll@0x69aaa 	
5 	js3250.dll 	js_Invoke 	js/src/jsinterp.cpp:1324
6 	xul.dll 	nsXPCWrappedJSClass::CallMethod 	js/src/xpconnect/src/xpcwrappedjsclass.cpp:1523
7 	xul.dll 	nsXPCWrappedJS::CallMethod 	js/src/xpconnect/src/xpcwrappedjs.cpp:565
8 	xul.dll 	PrepareAndDispatch 	xpcom/reflect/xptcall/src/md/win32/xptcstubs.cpp:114
9 	xul.dll 	SharedStub 	xpcom/reflect/xptcall/src/md/win32/xptcstubs.cpp:141
10 	xul.dll 	nsTreeBodyFrame::PrefillPropertyArray 	layout/xul/base/src/tree/src/nsTreeBodyFrame.cpp:2016
11 	xul.dll 	nsFrameManager::GetPrimaryFrameFor 	layout/base/nsFrameManager.cpp:342
12 	xul.dll 	nsTreeBodyFrame::PaintCell 	layout/xul/base/src/tree/src/nsTreeBodyFrame.cpp:3138
13 	xul.dll 	nsTreeColumn::GetRect 	layout/xul/base/src/tree/src/nsTreeColumns.cpp:149
14 		@0x457227f 	
15 		@0x1b2f

Comment 4

[IU]

(In reply to comment #3)
> and it does not crash without jit, right ?
> 
Right.  No crash without JIT chrome

Comment 5

[Nick]

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1b1pre) Gecko/20080913205356 Minefield/3.1b1pre ID:20080913205356

This build still causes a crash.  But I have also found something interesting.  If you first open the preferences menu with JIT:Chrome disabled, it will populate fine. You can close the window, renable JIT:Chrome, and it will not crash when you reopen the preferences window. 

However, just opening the preferences window with JIT:Chrome enabled, will cause a crash every time.

Comment 6

[IU]

(In reply to comment #5)
> You can close the window, renable JIT:Chrome, and it will not
> crash when you reopen the preferences window. 
> 
I hope you are first restarting Firefox after re-enabling JIT chrome.  Many have made this mistake and assumed a JIT chrome-related crash resolved -- only to find out otherwise.

Comment 7

[Ilja Sekler]

Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1b1pre) Gecko/20080914175448 Firefox/3.1b1pre

The crash opening AB+ preferences window with javascript.options.jit.chrome enabled happens equally on Linux. The last words of a debug build:

++WEBSHELL 0x8e16038 == 7
++DOMWINDOW == 11 (0x8e043fc) [serial = 11] [outer = (nil)]
++DOMWINDOW == 12 (0x8e9bd44) [serial = 12] [outer = 0x8e043d0]
WARNING: recurring into frame construction: 'mPresContext->mLayoutPhaseCount[eLayoutPhase_FrameC] == 0', file ../../dist/include/layout/nsPresContext.h, line 988
WARNING: GetDefaultCharsetForLocale: need to add multi locale support: file /home/ilja/mozilla/mozilla-central/src/intl/uconv/src/nsUNIXCharset.cpp, line 189
WARNING: recurring into frame construction: 'mPresContext->mLayoutPhaseCount[eLayoutPhase_FrameC] == 0', file ../../dist/include/layout/nsPresContext.h, line 988
Assertion failure: !tm->recorder, at /home/ilja/mozilla/mozilla-central/src/js/src/jstracer.cpp:2481
Trace/breakpoint trap

Please change OS to "All".

Comment 8

[frequenzy]

this problem can be reproduced easily. using vista64.

Comment 9

[IU]

Is anyone who confirmed this able to flag it as new?

Comment 10

[-fullmetaljacket-]

ok -> NEW

Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.1b1pre) Gecko/20080917034815 Minefield/3.1b1pre ID:20080917034815

Comment 11

[frequenzy]

just wondering if there are any updates on this?

Comment 12

[David Anderson [:dvander] - inactive, e-mail if emergency]

Attachment: proposed fix

Comment 13

[David Anderson [:dvander] - inactive, e-mail if emergency]

Pushed fix to tracemonkey branch as changeset http://hg.mozilla.org/tracemonkey/rev/c0895d880428

Will close on sync with mozilla-central.

Comment 14

[RFLazaro]

I believe Andreas agreed not to Resolved-Fixed a user reported JIT bug until it is synced and confirmed in MC

Comment 15

[Andreas Gal :gal]

TM and MC were synced yesterday night.

Comment 16

[RFLazaro]

Yes, but no one confirmed this yet using an MC build. I think it would be safe to keep it open until someone confirms using an MC build.

Comment 17

[Andreas Gal :gal]

I am open to either approach. 

I will try to find out what the preferred procedure is. CC'ing damon, maybe he has some insight when bugs should be closed in our someone unorthodox split tree model.

Comment 18

[RFLazaro]

Just to avoid confusion, my comments regarding confirmation are only applicable to this split tree model (tm syncing to mc).

Comment 19

[Brendan Eich [:brendan]]

Confirming a fix is usually done by making the bug VERIFIED. But it helps to know what patch fixed each bug, so one can make more deterministic tests. Too many WFM resolutions leave doubt; bugs come back to life when new ones should be filed, etc.

Nevertheless, if this bug should be marked fixed according to the hackers doing the fixing, they are free to mark it fixed. The two-trees model has nothing to do with this issue (provided the patch lands in m-c before the dev marks the bugs fixed).

/be

Comment 20

[Tony Chung [:tchung]]

Verified fix on Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US;
rv:1.9.1b3pre) Gecko/20090122 Shiretoko/3.1b3pre 
and Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.2a1pre)
Gecko/20090122 Minefield/3.2a1pre