After stopping at a breakpoint, all functions in the call stack remained around
for the lifetime of the mozilla process.
The problem involves the fact that debugger service depends on the XPCOM
JSDValue wrapper, jsdIValue, to call JSD_DropValue. It also tried to avoid
creating new wrappers by maintaining a list of live values.
If a client asked to wrap a JSDValue for which we already had a jsdIValue for
the *underlying jsval*, the existing wrapper would be returned. The unwrapped
JSDValue would never be dropped, leaking anything connected to it.
I think the whole idea is probably overkill. It's pretty easy to create
thousands of these wrappers browsing around some of the larger objects on the
window, and the exponential cost in search time starts to outweigh the memory
savings (5 pointers and a PRBool per jsdIValue.) Normal usage seems to point to
brief bursts of wrappers, destroyed when the user resumes execution. My best
SWAG is that the memory overhead due to duplicate wrappers is under 1k in
"likely" heavy use cases.
At the time I did this, the big advantage was being able to test for equality
among wrappers. These days I can unwrap the object and compare two jsvals directly.
I also took this opportunity to fix a few other issues...
* Convert a few raw pointers to nsCOMPtrs
* Fix a bug where removing the last filter did not null out the list head,
causing a crash the next time filters were used.
* Track live jsdStackFrames, so we can invalidate them all when execution
continues. Without this, only the top frame is properly invalidated, and any
other frame accessed after a continue will do Bad Things.
* Add some debugging prints to GetInitAtService, which seems to be failing at
random times.