42098 - Composer leaks nsEditorShell

Status: VERIFIED FIXED

(Core :: Layout, defect, P3)

Description

[Simon Fraser [no longer active]]

If you open and close a composer window (no typing required), we leak a bunch of 
stuff, including the nsEditor, nsEditorShell, nsEditorBoxObject, 2 nsJSContexts 
and perhaps more. This causes other teardown-related bugs (e.g. bug 41681).

Comment 1

[Simon Fraser [no longer active]]

We're leaking an nsXULDocument here

Comment 2

[Simon Fraser [no longer active]]

Attachment: refcount trace with --ignore-balanced, for mozilla -edit and quit

Comment 3

[rubydoo123]

*** Bug 41681 has been marked as a duplicate of this bug. ***

Comment 4

[Simon Fraser [no longer active]]

Status on this one:

If I remove the <editor> tag from the XUL, we stop leaking.
If I never make an editor in the C++, then we still leak.

Comment 5

[Simon Fraser [no longer active]]

Well, this was fun. It turns out to be a bug deep in XBL/JS, which I've filed 
separately (bug 42746). I can fix this by checking in a workaround.

Comment 6

[Simon Fraser [no longer active]]

Attachment: trace for editor shell leakage

Comment 7

[Simon Fraser [no longer active]]

I checked in a 1-line JS change that fixed the XUL doc leak. We still leak the 
editorshell, which is shown in the log just attached.

Comment 8

[Simon Fraser [no longer active]]

Tony, this one is all yours. FYI, here's an email which waterson sent out which 
relates to this bug:

David Baron has done a heroic job of tracking down and documenting a
plethora of leaks that involve XUL, JS, XBL, boxes, and editor. For
that, he certainly deserves a *ton* of credit. But that's not why I'm
writing this message.

I'm starting to get really, really nervous about the state of this code.
I think that a lot of stuff is just leaking all over the floor. And I
mean, really nasty, hard leaks that involve cycles between frames,
content nodes, and their JS objects. (For example, look at
http://bugzilla.mozilla.org/show_bug.cgi?id=45676.)

These leaks involve massive amounts of memory. For example, let's take
bug 45676. Just *using* a scrollbar (imagine that) entrains over 1Mb
(the entire window)! Realistically, this means that we're leaking almost
every window that we open.

I realize that people on XPToolkit are already doomed, but this stuff
has *got* to be made a priority. It has tremendous impact on performance
and footprint, and ultimately affects the stability of the product on
Win98, Mac, and embedded platforms.

Is there any hope that dbaron can get some help looking at this stuff?

thanks,
chris

Comment 9

[Simon Fraser [no longer active]]

keywords

Comment 10

[Simon Fraser [no longer active]]

Ugh, sorry for the spam. m18.

Comment 11

[rubydoo123]

Anthony -- pull in SImon if you need help with this one, setting to nsbeta3+

Comment 12

[rubydoo123]

setting priority in status whiteboard - medium

Comment 13

[rubydoo123]

moving this over to m19 with other perf issues

Comment 14

[rubydoo123]

bumping up to p2, setting to nsbeta3+ -- reviewed by Bijal and beppe

Comment 15

[selmer (gone)]

pdtp3.  There is nothing in this bug that describes the horrible impact of not
fixing it.  If you can show that fixing this would provide some huge benefit,
please bring it back for reconsideration.

Comment 16

[Simon Fraser [no longer active]]

This bug is fixed anyway.

Comment 17

[Chris Petersen]

Marking verified per last comments by reporter.