Closed Bug 701625 Opened 8 years ago Closed 7 years ago

Assertion failure: JS_GetContextThread(cx) and other fun during OOM and cycle collection

Categories

(Core :: XPConnect, defect, critical)

x86
Windows XP
defect
Not set
critical

Tracking

()

RESOLVED WORKSFORME
Tracking Status
firefox10 --- affected
firefox11 --- affected

People

(Reporter: bc, Unassigned)

References

(Depends on 1 open bug, Blocks 1 open bug, )

Details

(Keywords: assertion)

Seen on Aurora, Nightly - Windows 7 (most reliable) and Windows XP with 1-2G RAM.

1. http://kvartorg.com/search/?deal_type=1%26object_type=2%26city=%C3%83%C2%AF%C3%82%C2%BF%C3%82%C2%BD%C3%83%C2%AF%C3%82%C2%BF%C3%82%C2%BD%C3%83%C2%AF%C3%82%C2%BF%C3%82%C2%BD%C3%83%C2%AF%C3%82%C2%BF%C3%82%C2%BD%26pr_from=%26pr_to=%26filterdays=2%26submit=%C3%83%C2%AF%C3%82%C2%BF%C3%82%C2%BD%C3%83%C2%AF%C3%82%C2%BF%C3%82%C2%BD%C3%83%C2%AF%C3%82%C2%BF%C3%82%C2%BD%C3%83%C2%AF%C3%82%C2%BF%C3%82%C2%BD%C3%83%C2%AF%C3%82%C2%BF%C3%82%C2%BD%C3%83%C2%AF%C3%82%C2%BF%C3%82%C2%BD%C3%83%C2%AF%C3%82%C2%BF%C3%82%C2%BD%C3%83%C2%AF%C3%82%C2%BF%C3%82%C2%BD

2. 
###!!! ASSERTION: Uh, JS context w/o a thread?: 'cx->thread()', file c:\work\mozilla\builds\nightly\mozilla\js\xpconnect\src\xpcprivate.h, line 3661
Assertion failure: JS_GetContextThread(cx), at c:/work/mozilla/builds/nightly/mozilla/js/xpconnect/src/XPCThreadContext.cpp:138


>	mozjs.dll!JS_Assert(const char * s=0x5ff45878, const char * file=0x5ff45828, int ln=138)  Line 104	C++
 	xul.dll!XPCJSContextStack::Push(JSContext * cx=0x06d71e28)  Line 138 + 0x2c bytes	C++
 	xul.dll!XPCCallContext::Init(XPCContext::LangType callerLanguage=LANG_NATIVE, int callBeginRequest=1, JSObject * obj=0x00000000, JSObject * funobj=0x00000000, XPCCallContext::WrapperInitOptions wrapperInitOptions=INIT_SHOULD_LOOKUP_WRAPPER, jsid name={...}, unsigned int argc=4294967295, JS::Value * argv=0x00000000, JS::Value * rval=0x00000000)  Line 135 + 0x15 bytes	C++
 	xul.dll!XPCCallContext::XPCCallContext(XPCContext::LangType callerLanguage=LANG_NATIVE, JSContext * cx=0x06d71e28, JSObject * obj=0x00000000, JSObject * funobj=0x00000000, jsid name={...}, unsigned int argc=4294967295, JS::Value * argv=0x00000000, JS::Value * rval=0x00000000)  Line 64	C++
 	xul.dll!nsXPConnect::BeginCycleCollection(nsCycleCollectionTraversalCallback & cb={...}, bool explainLiveExpectedGarbage=false)  Line 468 + 0x36 bytes	C++
 	xul.dll!nsCycleCollector::BeginCollection(nsICycleCollectorListener * aListener=0x00000000)  Line 2734	C++
 	xul.dll!nsCycleCollectorRunner::Run()  Line 3504 + 0x12 bytes	C++

Other examples:

http://o001oo.ru/index.php?showtopic=14210%26st=0

 	mozjs.dll!JS_Assert(const char * s=0x5ff45878, const char * file=0x5ff45828, int ln=138)  Line 104	C++
 	xul.dll!XPCJSContextStack::Push(JSContext * cx=0x05973308)  Line 138 + 0x2c bytes	C++
 	xul.dll!XPCCallContext::Init(XPCContext::LangType callerLanguage=LANG_NATIVE, int callBeginRequest=1, JSObject * obj=0x00000000, JSObject * funobj=0x00000000, XPCCallContext::WrapperInitOptions wrapperInitOptions=INIT_SHOULD_LOOKUP_WRAPPER, jsid name={...}, unsigned int argc=4294967295, JS::Value * argv=0x00000000, JS::Value * rval=0x00000000)  Line 135 + 0x15 bytes	C++
 	xul.dll!XPCCallContext::XPCCallContext(XPCContext::LangType callerLanguage=LANG_NATIVE, JSContext * cx=0x05973308, JSObject * obj=0x00000000, JSObject * funobj=0x00000000, jsid name={...}, unsigned int argc=4294967295, JS::Value * argv=0x00000000, JS::Value * rval=0x00000000)  Line 64	C++
 	xul.dll!nsXPConnect::BeginCycleCollection(nsCycleCollectionTraversalCallback & cb={...}, bool explainLiveExpectedGarbage=false)  Line 468 + 0x36 bytes	C++
 	xul.dll!nsCycleCollector::BeginCollection(nsICycleCollectorListener * aListener=0x00000000)  Line 2734	C++
 	xul.dll!nsCycleCollectorRunner::Run()  Line 3504 + 0x12 bytes	C++

and 8 other urls. The common thread appears to be adding tons of images until you run out of memory and assert. You may end up with an OOM abort, but I reproduced these two url/assertions locally on Win7 with 2G.
Assertion failure: JS_GetContextThread(cx) is still occurring on a number of urls.

At http://congressoamericano.blogspot.com/p/fotos-do-congresso-americano-iii.html , automation on Window 7 32bit showed 

JavaScript Error: ["out of memory"]. Line: 0.
Assertion failure: lastProperty()->hasTable(), at c:/work/mozilla/builds/nightly/mozilla/js/src/jsscope.cpp:493

Upon trying to reproduce locally I hit Assertion failure: JS_GetContextThread(cx)

Other crashes on Beta/9, Aurora/10, Nightly/11 Windows XP and Windows 7 also appear with 

###!!! ASSERTION: You can't dereference a NULL nsAutoPtr with operator->().: 'mRawPtr != 0', file c:\work\mozilla\builds\nightly\mozilla\firefox-debug\dist\include\nsAutoPtr.h, line 183

###!!! ASSERTION: Changing refcount of nsScriptCacheCleaner object during Traverse is not permitted!: 'Error', file c:/work/mozilla/builds/nightly/mozilla/content/base/src/nsFrameMessageManager.cpp, line 876

http://thmakeupdesign.com/blog/ also exhibits Assertion failure: JS_GetContextThread(cx) in addition to Assertion failure: str, at c:\work\mozilla\builds\beta\mozilla\js\src\jsval.h:475 on Beta/9 only.

http://subscribe.ru/author/18450517/love on Beta/9, Aurora/10 exhibit  exhibits Assertion failure: JS_GetContextThread(cx) in addition to Assertion failure: verifiedRange, at c:\work\mozilla\builds\aurora\mozilla\js\src\methodjit\BaseCompiler.h:122

Again the common pattern is these sites contain large numbers of images which force us into an out of memory state which the js engine does not properly handle.
adding image-suck as a dependency as many of the js related crashes and assertions I see are due to oom conditions on pages containing many images.
Depends on: image-suck
Bug 689623 just landed, which helps a lot with image memory consumption.  Is this still a problem?
I resubmitted the urls in this bug to the crash test automation and only reproduced the no signature crash on beta/aurora on windows. Testing manually on Windows I did not see crashes or fatal assertions either. It did appear that I hit very high memory usage on http://congressoamericano.blogspot.com/p/fotos-do-congresso-americano-iii.html however.

Testing http://congressoamericano.blogspot.com/p/fotos-do-congresso-americano-iii.html locally on Fedora 18 x86_64 with 16G I loaded the url into a tab and watched the system monitor as firefox used over 3G of memory I did not interact with the page. I did notice the memory usage drop when I switched tabs and increase again when switching back. I noticed that when I scrolled the page, the memory usage dropped and remained lower. Not sure what to make of that.

I'll know more in coming days as the crash automation continues to test crash urls.

I'll call this wfm for now.
Status: NEW → RESOLVED
Closed: 7 years ago
Resolution: --- → WORKSFORME
With the Nightly from yesterday, http://congressoamericano.blogspot.com/p/fotos-do-congresso-americano-iii.html (which has hundreds of photos on it, displayed one at a time on a very long page) took up huge amounts of memory and my whole browser dragged to a crawl.  With today's Nightly, which I think is the first with bug 689623, the browser remains responsive.  So I think that's fixed.
You need to log in before you can comment on or make changes to this bug.