463829 - Crash on Google Reader When Attempting To Open Feed With It's All Text! Extension [@ js_BlacklistPC(nanojit::Fragmento*, nanojit::Fragment*) ]

Status: VERIFIED FIXED

(Core :: JavaScript Engine, defect)

Description

[WildcatRay]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1b2pre) Gecko/20081108 Minefield/3.1b2pre Firefox/3.0.3
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1b2pre) Gecko/20081108 Minefield/3.1b2pre Firefox/3.0.3

With today's Minefield build (Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1b2pre) Gecko/20081108 Minefield/3.1b2pre - Build ID: 20081108033239), I experienced the browser crashing when I tried to click on an RSS feed link in Google Reader. This was with JIT content enabled (true) and the extension It's All Text! enabled.

Crash signature: js_BlacklistPC(nanojit::Fragmento*, nanojit::Fragment*
Two crash reports: 0e4fb20a-adae-11dd-b36b-001a4bd43e5c & 3d221180-adaf-11dd-8b6e-001a4bd43e5c

Either disabling JIT content or the extension eliminated the crashing.

Reproducible: Always

Steps to Reproduce:
1. Install the extension It's All Text! using a new profile.
2. Open Google Reader.
3. Click on an RSS feed link.
Actual Results:  
Browser crashes and crash reporter dialog opens.

Expected Results:  
Google Reader should display items of the selected RSS feed link.

Comment 1

[WildcatRay]

It's All Text! on AMO: https://addons.mozilla.org/en-US/firefox/addon/4125

Comment 2

[WildcatRay]

FWIW-I have Java Platform SE 6 U10 (6.0.100.33) installed.

Comment 3

[Matthias Versen [:Matti]]

0  	js3250.dll  	js_BlacklistPC  	 js/src/jstracer.cpp:3645
1 	js3250.dll 	js_AbortRecording 	js/src/jstracer.cpp:3666
2 	js3250.dll 	js_Interpret 	js/src/jsinterp.cpp:4591
3 	xul.dll 	MOZ_XMLCheckQName

Comment 4

[Robert Sayre]

This is working for me on
Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1b2pre) Gecko/20081109 Minefield/3.1b2pre

Ray, does this still crash for you on a new nightly?

Comment 5

[WildcatRay]

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1b2pre) Gecko/20081114 Minefield/3.1b2pre - Build ID: 20081114034305

Still crashes for me even on a brand new profile. Same signature. Crash ID: 3753a207-53bc-4153-82b0-fa9720081114

This bug needs to be reopened.

Comment 6

[WildcatRay]

Just had the following crashes using today's Tracemonkey nightly on a profile with only It's All Text!, NTT, and Java Quick Starter installed:

f260f3fc-980b-41b0-9f9d-7a2a20081114
a4b27fd5-efe1-4453-a5e5-37a620081114
c0826202-6dd5-4622-aeda-872320081114

Browser build: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1b2pre) Gecko/20081114 Minefield/3.1b2pre ID:20081114021246

Comment 7

[Tony Chung [:tchung]]

This topcrash #6 on socorro on the 1.9.1b2pre nightly builds.

http://crash-stats.mozilla.com/?do_query=1&version=Firefox%3A3.1b2pre&query_search=signature&query_type=contains&query=&date=&range_value=1&range_unit=weeks

Comment 8

[Brendan Eich [:brendan]]

Any hope of a reduced testcase? If someone gets this in a debugger, please join #jsapi on irc.mozilla.org and ask for help poking in the live debugger.

/be

Comment 9

[Henrik Skupin [:whimboo][⌚️UTC+1]]

Same crash for me on Vista when opening the Venkman page on AMO. I'll give it a shot in my debugger. Brendan, if I need help I'll contact you.

Comment 10

[Henrik Skupin [:whimboo][⌚️UTC+1]]

Here the complete stack of my debug build under VC8:

>	js3250.dll!js_BlacklistPC(nanojit::Fragmento * frago=0x00000002, nanojit::Fragment * frag=0x00000000)  Line 3645	C++
 	js3250.dll!js_AbortRecording(JSContext * cx=0x05b45000, const char * reason=0x6978dcc1)  Line 3667	C++
 	js3250.dll!js_MonitorRecording(TraceRecorder * tr=0x00000000)  Line 3603 + 0x6 bytes	C++
 	js3250.dll!js_Interpret(JSContext * cx=)  Line 117 + 0x11 bytes	C++
 	js3250.dll!js_Invoke(JSContext * cx=0x05b45000, unsigned int argc=1, long * vp=0x02e72020, unsigned int flags=0)  Line 1324 + 0xa bytes	C++
 	js3250.dll!js_InternalInvoke(JSContext * cx=0x05b45000, JSObject * obj=0x05cb9da0, long fval=142367192, unsigned int flags=0, unsigned int argc=1, long * argv=0x0867332c, long * rval=0x0013f2f8)  Line 1381 + 0xf bytes	C++
 	js3250.dll!JS_CallFunctionValue(JSContext * cx=0x05b45000, JSObject * obj=0x05cb9da0, long fval=142367192, unsigned int argc=1, long * argv=0x0867332c, long * rval=0x0013f2f8)  Line 5242 + 0x27 bytes	C++
 	xul.dll!67ea4e86() 	
 	[Frames below may be incorrect and/or missing, no symbols loaded for xul.dll]	
 	xul.dll!67ebbee2() 	
 	xul.dll!67fc162b() 	
 	xul.dll!67f6d142() 	
 	xul.dll!67f6d0ab() 	
 	xul.dll!67f3c3e5() 	
 	xul.dll!67f5267a() 	
 	xul.dll!6804bd41() 	
 	xul.dll!67f89d67() 	
 	xul.dll!67f0c183() 	
 	xul.dll!67f0d9a6() 	
 	firefox.exe!wmain(int argc=2, wchar_t * * argv=0x0092d080)  Line 87 + 0xe6 bytes	C++
 	firefox.exe!__tmainCRTStartup()  Line 591 + 0x19 bytes	C
 	kernel32.dll!@BaseThreadInitThunk@12()  + 0x12 bytes	
 	ntdll.dll!___RtlUserThreadStart@8()  + 0x27 bytes	
 	ntdll.dll!__RtlUserThreadStart@8()  + 0x1b bytes

Comment 11

[Henrik Skupin [:whimboo][⌚️UTC+1]]

Just to give an update on this. After a talk with Brendan on IRC I found out that https://addons.mozilla.org/js/jquery.addons.min.js causes the crash. I've to update my debug build before having the chance to give more information.

Comment 12

[Henrik Skupin [:whimboo][⌚️UTC+1]]

Ray, do you have Firebug 1.3b or 1.4a installed? At least for me this extension causes this crash. Here the needed STR to crash Firefox:

1. Create a fresh profile
2. Install the lastest beta version of Firebug from http://getfirebug.com/releases/firebug/1.3/
3. Restart Firefox
4. Don't close the Add-ons Manager after the restart
5. Go to the "Get Add-ons" panel
6. Search for e.g. "Venkman"
7. Click on "See all results"

While a new tabs gets opened, Firefox will crash within some seconds while loading the page.

Comment 13

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

Reproduced -- am debugging.

Comment 14

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

Attachment: proposed fix (checked-in: comment 17)

Keeps outer recorders on a stack that js_FlushJITCache can walk and deep abort.  The fragment == NULL logic in TraceRecorder got taken out a while ago, this re-adds it so the actual recorder objects can stick around (necessary so jump tables don't get confused).

This lets us flush the cache but keep recording.

Comment 15

[Brendan Eich [:brendan]]

Comment on attachment 348299 [details] [diff] [review]
proposed fix (checked-in: comment 17)

gal should review the TraceRecorder dtor changes (which I've seen in the past, before the global shape zapping by the GC and deferred JIT cache clearing based on that).

Nit: preopositions in push and pop method names don't pay their way -- lose "Onto" and "off".

Can the deepAbort stuff be replaced by this mechanism? Neither is sufficient to prevent interpreter entry from trace, but we need one or other sooner.

/be

Comment 16

[Andreas Gal :gal]

Comment on attachment 348299 [details] [diff] [review]
proposed fix (checked-in: comment 17)

God this is hideous. We should at least get rid of the wasRootFragment business as soon we put the TreeInfo into the LIR buffer instead of using malloc.

Comment 17

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

Pushed fix as changeset: http://hg.mozilla.org/tracemonkey/rev/415a091bf8d9

Brendan: removed prepositions as requested.  

Agree that this is ugly - Andreas's idea would help the TreeInfo ownership logic.  This mechanism sort of relies on deepAbort because the stack needs to unwind properly (lest the jump tables get confused).  We could probably get rid of it if the abortStack was told how to patch up the interpreter's local variables.

Filed somewhat related bug 465124 to clean TreeInfo up.

Comment 18

[Bob Clary [:bc] (inactive)]

(In reply to comment #17)
> Pushed fix as changeset: http://hg.mozilla.org/tracemonkey/rev/415a091bf8d9

This caused js1_7/extensions/regress-455982-01.js to change from an assertion (bug 462142) to a CRASH

Comment 19

[Bob Clary [:bc] (inactive)]

fyi, js1_7/extensions/regress-455982-01.js's stack

Program received signal EXC_BAD_ACCESS, Could not access memory.
Reason: KERN_PROTECTION_FAILURE at address: 0x00000060
0x0009cd85 in TraceRecorder::wasDeepAborted (this=0x0) at jstracer.h:457
457	    bool wasDeepAborted() { return deepAborted; }
(gdb) bt
#0  0x0009cd85 in TraceRecorder::wasDeepAborted (this=0x0) at jstracer.h:457
#1  0x00060e4d in js_Interpret (cx=0x30b210) at ../jsinterp.cpp:2582
#2  0x000a07c6 in js_Invoke (cx=0x30b210, argc=0, vp=0x818460, flags=0) at jsinterp.cpp:1326
#3  0x000a0a7c in js_InternalInvoke (cx=0x30b210, obj=0x248000, fval=2621496, flags=0, argc=0, argv=0x0, rval=0xbfff98cc) at jsinterp.cpp:1383
#4  0x000a0cdd in js_InternalGetOrSet (cx=0x30b210, obj=0x248000, id=2402212, fval=2621496, mode=JSACC_READ, argc=0, argv=0x0, rval=0xbfff98cc) at jsinterp.cpp:1444
#5  0x000b2df5 in js_NativeGet (cx=0x30b210, obj=0x248000, pobj=0x248000, sprop=0x81ab50, vp=0xbfff98cc) at ../jsobj.cpp:3663
#6  0x000b3bb7 in js_GetPropertyHelper (cx=0x30b210, obj=0x248000, id=2402212, vp=0xbfff98cc, entryp=0x0) at ../jsobj.cpp:3812
#7  0x000b3c4a in js_GetProperty (cx=0x30b210, obj=0x248000, id=2402212, vp=0xbfff98cc) at ../jsobj.cpp:3824
#8  0x000a2b09 in CallEnumeratorNext (cx=0x30b210, iterobj=0x248680, flags=3, rval=0xbfff98cc) at ../jsiter.cpp:566
#9  0x000a2c19 in js_CallIteratorNext (cx=0x30b210, iterobj=0x248680, rval=0xbfff98cc) at ../jsiter.cpp:600
#10 0x0018512d in js_FastCallIteratorNext (cx=0x30b210, iterobj=0x248680) at ../jsbuiltins.cpp:249
#11 0x0028f469 in ?? ()
#12 0x0012fd23 in js_ExecuteTree (cx=0x30b210, f=0x31bc10, inlineCallCount=@0xbfffd6a8, innermostNestedGuardp=0xbfffc6c0) at ../jstracer.cpp:3432
#13 0x00146305 in js_MonitorLoopEdge (cx=0x30b210, inlineCallCount=@0xbfffd6a8) at ../jstracer.cpp:3727
#14 0x0006343b in js_Interpret (cx=0x30b210) at ../jsinterp.cpp:3100
#15 0x0009f2c4 in js_Execute (cx=0x30b210, chain=0x248000, script=0x3116c0, down=0x0, flags=0, result=0x0) at jsinterp.cpp:1554
#16 0x00019270 in JS_ExecuteScript (cx=0x30b210, obj=0x248000, script=0x3116c0, rval=0x0) at ../jsapi.cpp:5078
#17 0x000028f4 in Process (cx=0x30b210, obj=0x248000, filename=0xbffff646 "./regress-455982-01.js", forceTTY=0) at ../js.cpp:278
#18 0x0000821a in ProcessArgs (cx=0x30b210, obj=0x248000, argv=0xbffff4dc, argc=10) at ../js.cpp:518
#19 0x000094e5 in main (argc=10, argv=0xbffff4dc, envp=0xbffff508) at ../js.cpp:4030

Comment 20

[Bob Clary [:bc] (inactive)]

js1_8/extensions/regress-452476.js also crashes with this stack and is caused by this checkin. If you need help running the js tests prior to check in please let me know.

Comment 21

[WildcatRay]

Fixed AFAICT in Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1b2pre) Gecko/20081116 Minefield/3.1b2pre - Build ID: 20081116033829.

Was able to navigate to several different RSS Feeds on Google Reader and no crashes. Thx all.

BTW-I did try Henrik's STR using Firebug as posted in Comment 12, but could not reproduce crash. (Shrugs shoulders while rubbing chin.)

Comment 22

[Bob Clary [:bc] (inactive)]

filed bug 465192 on the regression caused by this checkin.

Comment 23

[Henrik Skupin [:whimboo][⌚️UTC+1]]

As per comment 17 the fix was only checked into the tracemonkey branch. At least you are running such a build it shouldn't be fixed right now. Or do I miss something?

Comment 24

[WildcatRay]

(In reply to comment #23)
> As per comment 17 the fix was only checked into the tracemonkey branch. At
> least you are running such a build it shouldn't be fixed right now. Or do I
> miss something?

According to the forum daily thread (http://forums.mozillazine.org/viewtopic.php?f=23&t=950715&start=0&st=0&sk=t&sd=a) Peter reports that this was partially checked in, whatever that means. Apparently, wherever he draws that information from, it is reporting that something from or of this bug has been landed in Trunk. Beyond that, I have nothing more that I am able to provide regarding this. (Again, shrugs shoulders while rubbing chin.)

Comment 25

[Henrik Skupin [:whimboo][⌚️UTC+1]]

Ok, this was also checked into mozilla-central:
http://hg.mozilla.org/mozilla-central/rev/415a091bf8d9

I'll also run some tests asap to verify the fix.

Comment 26

[Tony Chung [:tchung]]

(In reply to comment #25)
> Ok, this was also checked into mozilla-central:
> http://hg.mozilla.org/mozilla-central/rev/415a091bf8d9
> 
> I'll also run some tests asap to verify the fix.

setting to resolved fixed status.

Comment 27

[Aakash Desai [:aakashd]]

verified FIXED on Shiretoko: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1b4pre) Gecko/20090422 Shiretoko/3.5b4pre ID:20090422042031