Moved from bug 458844 comment 3 {{ From Serge Gautherie 2008-10-08 18:08:37 PST [Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9.1b2pre) Gecko/20081009 SeaMonkey/2.0a2pre] (home, optim default) (W2Ksp4) Same leak, with additional { 1 nsBaseDragService 24 nsNativeDragTarget } }} *** But it would (now) seem to be related to SVG rather than MathML. [Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9.1b2pre) Gecko/20081122 SeaMonkey/2.0a2pre] (home, optim default) (W2Ksp4) (http://hg.mozilla.org/mozilla-central/rev/5d37678a2482 +http://hg.mozilla.org/comm-central/rev/892e9f783d9e) With only { # svg-integration/ include svg-integration/reftest.list } I get { |<----------------Class--------------->|<-----Bytes------>|<----------------Objects---------------->|<--------------References-------------->| Per-Inst Leaked Total Rem Mean StdDev Total Rem Mean StdDev 0 TOTAL 43 716 263363 19 ( 468,51 +/- 678,57) 380704 36 ( 370,97 +/- 731,22) 119 nsBaseDragService 68 68 1 1 ( 1,00 +/- 0,00) 286 18 ( 28,11 +/- 9,28) 351 nsNativeDragTarget 36 648 94 18 ( 20,59 +/- 6,99) 358 18 ( 35,03 +/- 10,08) }

I wonder if this is some kind of regression, or new tests, as it seems it appeared between bug 458844 comment 0 and bug 458844 comment 3 times/builds.

[Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9.1b3pre) Gecko/20081128 Minefield/3.1b3pre] (home, optim default) (W2Ksp4) (http://hg.mozilla.org/mozilla-central/rev/2ba4924ee82e) (After fixing bug 464067,) This leak remains: { 1 nsBaseDragService 18 nsNativeDragTarget } with only { # svg/ include svg/reftest.list } or { # svg-integration/ include svg-integration/reftest.list }

(In reply to comment #1) > I wonder if this is some kind of regression, or new tests I confirm that I ran (all) the reftests with Firefox on 2008.10.07 and this leak wasn't reported yet.

The first step here is to figure out exactly which test(s) is leaking.

(In reply to comment #4) [Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9.2a1pre) Gecko/20081209 Minefield/3.2a1pre] (home, optim default) (W2Ksp4) (http://hg.mozilla.org/mozilla-central/rev/85507cfcdda8) I did some test runs with 'svg-integration' list only: running all non-'-extref' tests don't leak; running 1+ '-extref' test leaks '1 nsBaseDragService'; each run '-extref' test leaks '2 nsNativeDragTarget' (more).

Interesting, thanks!

Fun times. This leak doesn't happen on Mac. I'll dust off my Windows build.

OK, so on Windows: env XPCOM_MEM_LEAK_LOG=log.txt ../obj/firefox/dist/bin/firefox.exe -reftest layout/reftests/svg-integration/reftests.list log.txt then says: == BloatView: ALL (cumulative) LEAK STATISTICS nsTraceRefcntImpl::DumpStatistics: 569 entries As in, no leaks. This is a debug build from m-c changeset 1ea7f41ebd97.

(In reply to comment #8) [Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9.2a1pre) Gecko/20081211 Minefield/3.2a1pre] (home, optim default) (W2Ksp4) (http://hg.mozilla.org/mozilla-central/rev/0d2bceefc012) From a MSys prompt and my obj dir, I tried |time env XPCOM_MEM_LEAK_LOG=log.txt dist/bin/firefox.exe -P tstProfile -reftest layout/reftests/svg-integration/reftests.list| I got the same kind of output ... but "nothing" ran ... as in "real 0m0.703s" ! The "same", but from a Windows prompt: leak still there.

I certainly had a browser run. Make sure to quit firefox before testing. I'm just running from whatever prompt it is mozillabuild gives me. I suppose I can try the regular Windows command.exe tomorrow.

OK, running from the Windows command prompt I have the same result. Since you can actually reproduce the leak, care to produce the relevant balance tree? Or does that not work on Windows?

(In reply to comment #10) > I certainly had a browser run. Make sure to quit firefox before testing. (Here, the browser window opens and closes immediately: just a blink. I'm not running Firefox, except to run tests.) > I'm just running from whatever prompt it is mozillabuild gives me. I suppose I > can try the regular Windows command.exe tomorrow. (I'm using mozbuild to run make, for compilation and TUnit tests, no more. cmd.exe nowadays ;->) (In reply to comment #11) > OK, running from the Windows command prompt I have the same result. Guessing, the differences on my side could be: Windows 2000, --disable-vista-sdk-requirements (!), --enable-logrefcnt instead of --enable-debug. > Since you can actually reproduce the leak, care to produce the relevant balance > tree? Or does that not work on Windows? I'll try again ... but the few times I tried not so long ago, the result did not seem much useful.

> (Here, the browser window opens and closes immediately: just a blink. Uh... it takes longer than that to run the reftests. You should see a browser window with the tests running in it until they finish. I'll see if I can get together an opt build, but that will take a few days at least; trying to compile in Windows more or less shuts everything down.

Can't reproduce on linux.

Windows nsNativeDragTarget is doing some manual refcounting :/

Smaug, can you take a look at this? If this isn't something you can do, can you suggest another owner? Boris, how about you? Assigning to Smaug for now. This is a blocker and needs an owner.

Unfortunately I don't have any Windows development machines. Neil, could you look at this?

Going ahead and assigning to Neil.

Serge, I just read through this bug again, and is it correct that this only shows up in Seamonkey, not Firefox, when running the svg-integration reftests?

No(t only): (see comment 2) it's Firefox too and svg too. Yet, I didn't test svg in a comment 5 detailed way.

Ok, at this point I'm kinda lost. Can you please give clear steps to reproduce this in Firefox?

My (clear !?) steps are simply to build then run (ref)tests: see comment 5, comment 9 and comment 12. What remains to be done (by me) is to (confirm and) narrow down the (comment 1 and comment 3) regression timeframe, which looks like to be http://hg.mozilla.org/mozilla-central/pushloghtml?startdate=2008-10-07&enddate=2008-10-10

Well, I can't reproduce using those steps, so clearly something else is going on, no?

(In reply to comment #22) > and comment 3) regression timeframe, which looks like to be > http://hg.mozilla.org/mozilla-central/pushloghtml?startdate=2008-10-07&enddate=2008-10-10 Actually, I ran the tests on 2008-10-07, but the build was most probably a little older. [Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9.1b1pre) Gecko/20090210014810 Minefield/3.1b1pre] (home, optim default) (W2Ksp4) (http://hg.mozilla.org/mozilla-central/rev/a2d84821ea71) Leaks, as soon as (all) bug 433616 patches landed initially: http://hg.mozilla.org/mozilla-central/pushloghtml?startdate=2008-09-28+12%3A00&enddate=2008-09-28+12%3A30 [Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9.1b1pre) Gecko/20090209 Minefield/3.1b1pre] (home, optim default) (W2Ksp4) (http://hg.mozilla.org/mozilla-central/rev/759221990d16) Test files not relanded yet. These tests were added by bug 433616: 43d2ee100f3b 2008-09-28 15:16:34 -0400 added Sep 28 12:19:00 2008 -0700 b456877d519a 2008-09-29 08:51:29 -0400 deleted Sep 29 06:27:17 2008 -0700 06169936afdb 2008-09-28 15:16:34 -0400 added Oct 06 09:08:22 2008 -0700 [Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9.1b1pre) Gecko/20090210 Minefield/3.1b1pre] (home, optim default) (W2Ksp4) (http://hg.mozilla.org/mozilla-central/rev/06169936afdb) Leaks, as soon as the tests relanded: http://hg.mozilla.org/mozilla-central/pushloghtml?startdate=2008-10-05+20%3A45&enddate=2008-10-06+09%3A10 (In reply to comment #20) > Yet, I didn't test svg in a comment 5 detailed way. Both landings added use-01-extref.svg, which leaks 4 nsNativeDragTarget (instead of "expected" 2). Initial changeset a2d84821ea71 (and later changeset ffbab1273403) added use-02-extref.svg, which reports the same leak(s). I can't say that it's a regression anymore: I can only say that these new tests "trigger/reveal" the leak(s). (In reply to comment #23) > Well, I can't reproduce using those steps, so clearly something else is going > on, no? Obviously, but I (still) don't know what other differences between my computer/environment and yours would be involved in triggerring this bug...

I mean.. why is any drag code involved in reftest at all, for example? That in itself is really really weird. Do you see the leaks when running reftest against a clean profile?

(In reply to comment #25) > why is any drag code involved in reftest at all, for example? I would have no idea. (If it's something broken on my computer, I would think of bug 443331; yet it's supposed not to happen with local builds...) > Do you see the leaks when running reftest against a clean profile? Yes: even with new bug 468913 runreftest.py temp profile. Hopefully, bug 469518 will be able to help shortly. *** While working on the latter, I noticed that python ...\runreftest.py ...\layout\reftests\reftest-sanity\reftest.list has this bug too: { HTTP(..) == filter-1.xhtml filter-1-ref.xhtml HTTP(..) == filter-2.xhtml filter-2-ref.xhtml } NB: There might be others yet; I would guess that, for quite a while, I have been testing svg and svg-integration only.

(In reply to comment #12) > (I'm using mozbuild to run make, for compilation and TUnit tests, no more. > cmd.exe nowadays ;->) Fwiw, I eventually tried |make reftest| from a MSys Bash shell: same leak as calling Python manually from Win2K cmd.exe.

(In reply to comment #26) > Hopefully, bug 469518 will be able to help shortly. Bug 469518 comment 25: { *Bug 466376 is then specific to my computer :-< }

Fwiw, I see this leak when running |include ../../layout/svg/crashtests/crashtests.list| too.

[Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9.2a1pre) Gecko/20090711 SeaMonkey/2.1a1pre] (home, optim default) (W2Ksp4) (http://hg.mozilla.org/mozilla-central/rev/47bfcd275ede +http://hg.mozilla.org/comm-central/rev/291cbe3374b9) R.Invalid, after upgrading to recent TortoiseHg v0.8.