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

VERIFIED FIXED

Status

()

Core
JavaScript Engine
--
critical
VERIFIED FIXED
10 years ago
7 years ago

People

(Reporter: WildcatRay, Assigned: dvander)

Tracking

({crash, regression, verified1.9.1})

Trunk
x86
Windows XP
crash, regression, verified1.9.1
Points:
---
Dependency tree / graph
Bug Flags:
blocking1.9.1 +
in-testsuite -
in-litmus -

Firefox Tracking Flags

(Not tracked)

Details

(crash signature, URL)

Attachments

(1 attachment)

(Reporter)

Description

10 years ago
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.
(Reporter)

Updated

10 years ago
Flags: blocking-firefox3.1?
Keywords: regression
Whiteboard: tracemonkey
Version: unspecified → Trunk
(Reporter)

Comment 1

10 years ago
It's All Text! on AMO: https://addons.mozilla.org/en-US/firefox/addon/4125
(Reporter)

Comment 2

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

Updated

10 years ago
Assignee: nobody → general
Component: Extension Compatibility → JavaScript Engine
Flags: blocking-firefox3.1?
Product: Firefox → Core
QA Contact: extension.compatibility → general

Updated

10 years ago
Blocks: 451602
Whiteboard: tracemonkey

Updated

10 years ago
Keywords: crash
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
Severity: normal → critical
Summary: Crash on Google Reader When Attempting To Open Feed With It's All Text! Extension Enabled → Crash on Google Reader When Attempting To Open Feed With It's All Text! Extension [@ js_BlacklistPC(nanojit::Fragmento*, nanojit::Fragment*) ]

Comment 4

10 years ago
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?

Updated

10 years ago
Status: UNCONFIRMED → RESOLVED
Last Resolved: 10 years ago
Resolution: --- → WORKSFORME
(Reporter)

Comment 5

10 years ago
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.
Status: RESOLVED → UNCONFIRMED
Resolution: WORKSFORME → ---
(Reporter)

Comment 6

10 years ago
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

10 years ago
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
Status: UNCONFIRMED → NEW
Ever confirmed: true
Flags: blocking1.9.1?
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
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.
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
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.
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.
Reproduced -- am debugging.
Assignee: general → danderson
Created attachment 348299 [details] [diff] [review]
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.
Attachment #348299 - Flags: review?(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
Attachment #348299 - Flags: review?(brendan) → review+

Updated

10 years ago
Attachment #348299 - Flags: review?(gal) → review+

Comment 16

10 years ago
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.
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.
(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
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
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.
Attachment #348299 - Attachment description: proposed fix → proposed fix (checked-in: comment 17)
(Reporter)

Comment 21

10 years ago
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.)
filed bug 465192 on the regression caused by this checkin.
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?
(Reporter)

Comment 24

10 years ago
(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.)
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

10 years ago
(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.
Status: NEW → RESOLVED
Last Resolved: 10 years ago10 years ago
Resolution: --- → FIXED

Updated

10 years ago
Flags: blocking1.9.1? → blocking1.9.1+
Keywords: fixed1.9.1
Status: RESOLVED → VERIFIED
Flags: in-testsuite-
Flags: in-litmus-
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
Keywords: fixed1.9.1 → verified1.9.1
Crash Signature: [@ js_BlacklistPC(nanojit::Fragmento*, nanojit::Fragment*) ]
You need to log in before you can comment on or make changes to this bug.