389734 - JS component fastload leaks when it can't open a JS component

Status: RESOLVED INACTIVE

(Core :: XPConnect, defect)

Description

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

When the JS component loader can't open a JS component, we leak because we don't break a cycle.  (I think we also never successfully use fastload, since we seem to be rereading the components every time.)

Steps to reproduce:
 1. Create a symlink in dist/bin/components/ that points to a nonexistent file.  (This happens in people's trees when a JS component is removed.)
 2. export XPCOM_MEM_LEAK_LOG=leak.log
 3. ./firefox (although I was actually testing using the bloatCycle.html leak test)

We leak the nsFastLoadFileUpdater through its nsCOMPtr pointing to itself:
Object 1 held by 0x09EFA33C is 1 out of balance.

Put into nsCOMPtr at:
nsCOMPtr<nsIFastLoadFileIO>::assign_assuming_AddRef(nsIFastLoadFileIO*) (/builds/trunk/obj/firefox-debugopt/xpcom/io/../../dist/include/xpcom/nsCOMPtr.h:566)
nsCOMPtr<nsIFastLoadFileIO>::assign_with_AddRef(nsISupports*) (/builds/trunk/obj/firefox-debugopt/xpcom/io/../../dist/include/xpcom/nsCOMPtr.h:1236)
nsCOMPtr<nsIFastLoadFileIO>::operator=(nsIFastLoadFileIO*) (/builds/trunk/obj/firefox-debugopt/xpcom/io/../../dist/include/xpcom/nsCOMPtr.h:714)
nsFastLoadFileUpdater::Open(nsFastLoadFileReader*) (/builds/trunk/mozilla/xpcom/io/nsFastLoadFile.cpp:2538)
NS_NewFastLoadFileUpdater(nsIObjectOutputStream**, nsIOutputStream*, nsIObjectInputStream*) (/builds/trunk/mozilla/xpcom/io/nsFastLoadFile.cpp:2573)
nsFastLoadService::StartMuxedDocument(nsISupports*, char const*, int) (/builds/trunk/mozilla/xpcom/io/nsFastLoadService.cpp:296)
mozJSComponentLoader::ReadScript(nsIFastLoadService*, char const*, nsIURI*, JSContext*, JSScript**) (/builds/trunk/mozilla/js/src/xpconnect/loader/mozJSComponentLoader.cpp:961)
mozJSComponentLoader::GlobalForLocation(nsILocalFile*, JSObject**, char**) (/builds/trunk/mozilla/js/src/xpconnect/loader/mozJSComponentLoader.cpp:1115)
mozJSComponentLoader::LoadModule(nsILocalFile*, nsIModule**) (/builds/trunk/mozilla/js/src/xpconnect/loader/mozJSComponentLoader.cpp:599)
nsComponentManagerImpl::AutoRegisterComponent(nsILocalFile*, nsTArray<DeferredModule>&, int) (/builds/trunk/mozilla/xpcom/components/nsComponentManager.cpp:3034)
nsComponentManagerImpl::AutoRegisterDirectory(nsIFile*, nsCOMArray<nsILocalFile>&, nsTArray<DeferredModule>&) (/builds/trunk/mozilla/xpcom/components/nsComponentManager.cpp:2950)
nsComponentManagerImpl::AutoRegisterImpl(nsIFile*, nsCOMArray<nsILocalFile>&, nsTArray<DeferredModule>&) (/builds/trunk/mozilla/xpcom/components/nsComponentManager.cpp:2908)
nsComponentManagerImpl::AutoRegister(nsIFile*) (/builds/trunk/mozilla/xpcom/components/nsComponentManager.cpp:3308)
ScopedXPCOMStartup::DoAutoreg() (/builds/trunk/mozilla/toolkit/xre/nsAppRunner.cpp:925)
XRE_main (/builds/trunk/mozilla/toolkit/xre/nsAppRunner.cpp:2873)
main (/builds/trunk/mozilla/browser/app/nsBrowserApp.cpp:153)
__libc_start_main (/usr/src/debug/glibc-20070515T2025/csu/libc-start.c:254)

which is supposed to be broken when its Close method is called.

However, because the symlink is bad, OpenNSPRFileDesc fails, so we return from GlobalForLocation after that call:
WARNING: NS_ENSURE_TRUE(NS_SUCCEEDED(rv)) failed: file /builds/trunk/mozilla/js/src/xpconnect/loader/mozJSComponentLoader.cpp, line 1166.  I'm not sure what the normal codepath for calling Close is (maybe through EndMuxedDocument?).  It also seems a little odd to me that we call StartMuxedDocument twice (once from ReadScript, which returns NS_ERROR_NOT_AVAILABLE but still leaves stuff that needs to be torn down, and then once from WriteScript) from the JS component loader in the case that we're writing; it seems like only one call should be needed.  Although maybe both are, in which case the fastload service should probably return NS_ERROR_NOT_AVAILABLE earlier.

(We also seem to be trying to load each of the bad components twice.)

Comment 3

[Alex Keybl [:akeybl]]

sirisha, please renominate with justification for why this should track. Please note that we only track new regressions.

Comment 4

[Andrew McCreight [:mccr8]]

I'm not sure if this still applies, as nsFastLoadFileUpdater and nsFastLoadFile.cpp don't seem to exist any more.

Comment 5

[BMO Automation]

Per policy at https://wiki.mozilla.org/Bug_Triage/Projects/Bug_Handling/Bug_Husbandry#Inactive_Bugs. If this bug is not an enhancement request or a bug not present in a supported release of Firefox, then it may be reopened.