733009 - OOM Crash [@ PR_JoinThread]

Status: RESOLVED DUPLICATE of bug 815847

(Core :: XUL, defect)

Description

[Christian Holler (:decoder)]

Tested on m-c revision 8ea5c983743f: During OOM testing I got the following crash, which I am not able to reproduce reliably (likely due to thread scheduling):

Program received signal SIGSEGV, Segmentation fault.PR_JoinThread (thred=0xc41170000000713) at /srv/repos/browser/mozilla-central/nsprpub/pr/src/pthreads/ptthread.c:543
543         if ((0xafafafaf == thred->state)
#0  PR_JoinThread (thred=0xc41170000000713) at /srv/repos/browser/mozilla-central/nsprpub/pr/src/pthreads/ptthread.c:543
#1  0x00002aaaac5d02fe in WaitOnWriteThread (this=0x2aaabc675840) at /srv/repos/browser/mozilla-central/startupcache/StartupCache.cpp:526
#2  mozilla::scache::StartupCache::WaitOnWriteThread (this=0x2aaabc675840) at /srv/repos/browser/mozilla-central/startupcache/StartupCache.cpp:519
#3  0x00002aaaac5d1083 in mozilla::scache::StartupCache::GetBuffer (this=0x2aaabc675840, id=0x2aaabe871648 "xulcache/resource/gre/chrome/toolkit/content/global/editMenuOverlay.xul", outbuf=0x7fffffffa9e0, length=0x7fffffffaa04) at /srv/repos/browser/mozilla-central/startupcache/StartupCache.cpp:329
#4  0x00002aaaaca9a173 in nsXULPrototypeCache::GetInputStream (this=0x2aaabd6036f0, uri=0x2aaabd4ec060, stream=0x7fffffffaaa8) at /srv/repos/browser/mozilla-central/content/xul/document/src/nsXULPrototypeCache.cpp:440
#5  0x00002aaaaca9ae72 in nsXULPrototypeCache::GetPrototype (this=0x2aaabd6036f0, aURI=0x2aaabd4ec060) at /srv/repos/browser/mozilla-central/content/xul/document/src/nsXULPrototypeCache.cpp:186
#6  0x00002aaaaca91453 in nsXULDocument::LoadOverlayInternal (this=0x2aaabc9bf4a0, aURI=0x2aaabd4ec060, aIsDynamic=false, aShouldReturn=0x7fffffffac4f, aFailureFromContent=0x7fffffffac4e) at /srv/repos/browser/mozilla-central/content/xul/document/src/nsXULDocument.cpp:2696
#7  0x00002aaaaca9791b in nsXULDocument::ResumeWalk (this=0x2aaabc9bf4a0) at /srv/repos/browser/mozilla-central/content/xul/document/src/nsXULDocument.cpp:3080
=> 0x2aaaaaafe5aa <PR_JoinThread+26>:   cmpl   $0xafafafaf,(%rbx)
rbx            0xc41170000000713        883012290708768531


The backtrace of the failing allocation is as follows:

#0 /srv/repos/browser/mozilla-central/objdir-ff-gcc64dbg/dist/bin/libmozalloc.so(moz_malloc+0x5f)
#1 nsVoidArray::SizeTo(int) at objdir-ff-gcc64dbg/xpcom/build/nsVoidArray.cpp:231
#2 nsVoidArray::InsertElementAt(void*, int) at objdir-ff-gcc64dbg/xpcom/build/nsVoidArray.cpp:457
#3 nsCOMArray_base::InsertObjectAt(nsISupports*, int) at objdir-ff-gcc64dbg/xpcom/build/nsCOMArray.cpp:83
#4 nsObserverList::FillObserverArray(nsCOMArray<nsIObserver>&) at xpcom/ds/nsObserverList.cpp:104
#5 nsObserverList::NotifyObservers(nsISupports*, char const*, unsigned short const*) at xpcom/ds/nsObserverList.cpp:129
#6 nsObserverService::NotifyObservers(nsISupports*, char const*, unsigned short const*) at xpcom/ds/nsObserverService.cpp:185
#7 mozilla::ShutdownXPCOM(nsIServiceManager*) at xpcom/build/nsXPComInit.cpp:614
#8 ~ScopedXPCOMStartup at toolkit/xre/nsAppRunner.cpp:1115
#9 /srv/repos/browser/mozilla-central/objdir-ff-gcc64dbg/dist/bin/libxul.so(XRE_main+0x3adb)
#10 /srv/repos/browser/mozilla-central/objdir-ff-gcc64dbg/dist/bin/firefox-bin()
#11 /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xed)
#12 /srv/repos/browser/mozilla-central/objdir-ff-gcc64dbg/dist/bin/firefox-bin()

Comment 1

[(no longer active)]

I think the problem here is that nsXULPrototypeCache.cpp holds its own gStartupCache pointer instead of calling StartupCache::GetSingleton() when it needs such a pointer, which causes it to not be able to cleanup its gStartupCache pointer when the startup cache goes away, which results in a use after free error.

Comment 2

[(no longer active)]

That being said, why this code is getting triggered during the shutdown process is beyond me.

Comment 3

[Al Billings [:abillings - ex-MoCo]]

Can anyone offer a security rating recommendation for this?

Comment 4

[Andrew McCreight [:mccr8]]

prototype cache oom at shutdown due to resetting the cache doesn't seem like too much of a problem.