Steven Michaud [:smichaud] (Retired) Reporter
	Description • 15 years ago

At least on OS X, the browser's nsAppShell/nsBaseAppShell object is
leaked almost 100% of the time when the browser relaunches.  In other
words, when the browser (briefly) runs and then automatically quits
and relaunches, the first instance (the one that triggers the
relaunch) has this leak.

I'm not sure how important this is.  And (as we shall see) it may be
impractical to fix it "at the source".  I'm opening this bug because
the issue came up in bug 472773.

The (single) nsBaseAppShell object leaks because the main thread's
nsThread object also leaks, and the nsBaseAppShell object has been
made an observer of the main thread's nsThread object (using
nsIThreadInternal::SetObserver(), in nsBaseAppShell::Init()).

The main thread's nsThread object leaks because two objects holding
strong references to it (the nsIdleServiceX object and an nsTimerImpl
object) are leaked.  These last two objects are "native" XPCOM objects
"wrapped" by XPConnect for use in JavaScript (each is the mIdentity
member of an XPCWrappedNative object), which are themselves leaked on
relaunch (along with several other XPCWrappedNative objects).

The reason these leaks don't normally happen is that (as best I can
tell) all XPCWrappedNative objects are normally "dead" (i.e. garbage
collectible) by the time the XPConnect destructor is called.  But (for
complicated reasons) this isn't true on relaunch.

The XPConnect destructor shuts down garbage collection of its objects
(in the calls to XPCWrappedNativeScope::SystemIsBeingShutDown(cx) and
mRuntime->SystemIsBeingShutDown(cx)).  And, though beforehand it
triggers one final round of forced garbage collection (in the call to
XPCPerThreadData::CleanupAllThreads()), none of the still-"alive"
XPCWrappedNative objects can be GC-ed during this call -- because
JS_CallTracer(), called indirectly (via js_TraceRuntime()) from
js_GC(), first sets all of their GCF_MARK flags (thus temporarily
preventing them from being GC-ed).

I haven't been able to figure out why, on relaunch, some
XPCWrappedNative objects are still "alive".  But I did notice that, on
relaunch, the nsIdleServiceX object gets created (and "wrapped") very
late -- after the ScopedXPCOMStartup destructor has been called from
XRE_main().  I'll bet other wrappers are also created very "late", and
that this has something to do with it.

	Steven Michaud [:smichaud] (Retired) Reporter
	Comment 1 • 15 years ago

Here's a patch which shows that the nsAppShell and main-thread leaks
are caused by problems with XPCWrappedNative objects.  A tryserver
build of it should show up in a few hours.

The original code tells us we shouldn't do this (so my patch isn't a
fix).  So I don't think it's currently practical to try to fix the
these leaks "at the source".

For now, it's better to work around them in other ways (as for example
my patch for bug 472773 does).

	Serge Gautherie (:sgautherie)
	Comment 2 • 15 years ago

Could you attach a leak log?
Is this the same as bug 478520 '-silent' case?

	Steven Michaud [:smichaud] (Retired) Reporter
	Comment 3 • 15 years ago

> Could you attach a leak log?

Please tell me how to generate one.

> Is this the same as bug 478520 '-silent' case?

Yes.  Exactly the same leak(s) happen when I do 'firefox-bin -silent'
(whether or not on relaunch) as when I do 'firefox-bin' and it
relaunches.

Here's a list (generated by my own logging) of the mIdentity objects
leaked by XPCWrappedNative::SystemIsBeingShutDown() (on relaunch, or
when using -silent).  I got the class names using RTTI. 

  mIdentity 13BackstagePass (0x006523A4)
  mIdentity 17nsObserverService (0x00637330)
  mIdentity 6nsJSID (0x006DF760)
  mIdentity 13BackstagePass (0x006523A4)
  mIdentity 13nsPrefService (0x0064A630)
  mIdentity 14nsIdleServiceX (0x006CD3F0)
  mIdentity 17nsObserverService (0x00637330)
  mIdentity 11nsTimerImpl (0x00D82720)
  mIdentity 13nsPrefService (0x0064A630)
  mIdentity 13BackstagePass (0x006523A4)
  mIdentity 14nsNavBookmarks (0x00D5D350)
  mIdentity 6nsJSID (0x00C5FCC0)

	Serge Gautherie (:sgautherie)
	Comment 4 • 15 years ago

(In reply to comment #3)

> > Could you attach a leak log?

Not needed anymore.

> Please tell me how to generate one.

Fyi, simply see XPCOM_MEM_LEAK_LOG at
https://developer.mozilla.org/en/Debugging_memory_leaks

> Yes.  Exactly the same leak(s) happen when I do 'firefox-bin -silent'

Thanks for the confirmation.

	BMO Automation
	Comment 5 • 6 years ago

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.