Bugzilla

Comment 1

•

16 years ago

Can you point me to the relevant pushlog regression range?

Reporter

Comment 2

•

16 years ago

(In reply to comment #0)
> http://hg.mozilla.org/releases/mozilla-1.9.1/pushloghtml?fromchange=81e6d7bc9161&tochange=a05e3e37e030

Comment 3

•

16 years ago

Hmm.  The XBL patch got backed out (and then relanded the next day).  Did that affect things?

Reporter

Comment 4

•

16 years ago

(In reply to comment #3)
> The XBL patch got backed out (and then relanded the next day).  Did that
> affect things?

It did not:

(In reply to comment #0)
> http://tinderbox.mozilla.org/showlog.cgi?log=SeaMonkey/1231888849.1231893570.9880.gz
> Win2k3 comm-central dep unit test on 2009/01/13 15:20:49
(http://hg.mozilla.org/releases/mozilla-1.9.1/pushloghtml?fromchange=a0d75a7e0719&tochange=d2165c8133c3)

Confirmed on Linux:
http://tinderbox.mozilla.org/showlog.cgi?log=SeaMonkey/1231888268.1231892093.7878.gz
Linux comm-central dep unit test on 2009/01/13 15:11:08

Then, out of the 5 checkins, this leaves:
Dao: bug 472302.
Boris: bug 449780, bug 465993.

Comment 5

•

16 years ago

Can you reproduce locally?  If so, can you try local backouts?

I'd be quite suprised if this is bug 465993, but it might be if the tests open windows with an invisible parent.  Bug 449780 is pretty unlikely, unless there are tests for swapping the "set up for undo tab close" tabs Seamonkey does.

Bug 472302 directly touched code involved in tests, so I'd probably start there.

Reporter

Comment 6

•

16 years ago

[Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9.2a1pre) Gecko/20090118 SeaMonkey/2.0a3pre] (experimental/_m-c_, home, optim default) (W2Ksp4)
(http://hg.mozilla.org/mozilla-central/rev/a12bffb28598
+http://hg.mozilla.org/comm-central/rev/306be9e163b0)

Leak report as expected:
none on boxes, and bug 458484 locally only.

[Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9.2a1pre) Gecko/20090118 SeaMonkey/2.0a3pre] (experimental/_m-c_, home, optim default) (W2Ksp4)
(http://hg.mozilla.org/mozilla-central/rev/6e4203c77ce9
+http://hg.mozilla.org/comm-central/rev/306be9e163b0)

New leak:
1,112 on boxes and locally;
with no more bug 458484 locally...
As if a leak was fixed and another one triggered :-|

(In reply to comment #5)
> Bug 472302 directly touched code involved in tests

Indeed:
http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=a12bffb28598&tochange=6e4203c77ce9

Blocks: 472302

Reporter

Updated

•

16 years ago

Component: General → XUL Widgets

Product: Core → Toolkit

QA Contact: general → xul.widgets

Version: 1.9.1 Branch → Trunk

Comment 7

•

16 years ago

I assume this widget is also used by Firefox, so in practice the leak wouldn't just affect Seamonkey?  Or is the leak involving Seamonkey-specific code somewhere?

Reporter

Comment 8

•

16 years ago

I tested (bug 458484) with test_idcheck.xul only, which is SM specific (not FF nor TB).
I'll check later if I can reproduce without using this very test...

Reporter

Comment 9

•

16 years ago

[Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9.2a1pre) Gecko/20090117 SeaMonkey/2.0a3pre] (experimental/_m-c_, home, optim default) (W2Ksp4)
(http://hg.mozilla.org/mozilla-central/rev/a3abe1807f71 + bug 446300 patch
 +http://hg.mozilla.org/comm-central/rev/da4ab57196d6 + bug 446300 patch)

Indeed, this leak is triggered by the following part test_idcheck.xul:
{{
        // Browser
        "chrome://navigator/content/navigator.xul":
          [
            window.CheckGenerics,
            ["contentAreaContextSet"]
          ],
}}

Depends on: 446281

Summary: [SeaMonkey] Chrome tests: new 1,112 bytes leak on 2009-01-13 → [SeaMonkey] Chrome (suite) test_idcheck.xul > navigator.xul : new 1,112 bytes leak on 2009-01-13

Comment 10

•

16 years ago

I think we should make some test_idcheck.xul tests for Firefox and Thunderbird as well, checking for duplicate element IDs in the main windows should be a good idea everywhere, and it has the nice side effect of checking all those for leaks as well.

Reporter

Comment 11

•

16 years ago

(In reply to comment #10)
> I think we should make some test_idcheck.xul tests for Firefox and Thunderbird
> as well

I concur: (Toolkit and) Firefox should be +/- easy to do,
but Thunderbird does not run mochitests (yet)...

Before filing a bug about that, do you think it should be copied to Firefox or could be shared in Toolkit ?

Comment 12

•

16 years ago

Better to ask Mnyromyr about this, he wrote test_idcheck.xul, AFAIK

Karsten Düsterloh

Comment 13

•

16 years ago

Basically, test_idcheck.xul should be able to run with any XUL app which uses the Mozilla testing framework, given a suitable uriList. It may be even possible to apply certain error checking and just stuff all uris for SM/FF/TB into the uriList - I didn't try...

Comment 14

•

16 years ago

OK, so IIUC, we're understanding this leak now, so I adjusted the thresholds in http://hg.mozilla.org/build/buildbot-configs/rev/5fe4bc6513e5 and restarted the master.

Comment 15

•

16 years ago

I filed bug 474716 on adding test_idcheck for Firefox.

Reporter

Comment 16

•

16 years ago

(In reply to comment #9)
>         "chrome://navigator/content/navigator.xul":

And, more precisely, its
<?xul-overlay href="chrome://navigator/content/navigatorOverlay.xul"?>

Reporter

Comment 17

•

16 years ago

(In reply to comment #16)
> >         "chrome://navigator/content/navigator.xul":
> 
> <?xul-overlay href="chrome://navigator/content/navigatorOverlay.xul"?>

And, more precisely, its

          <menupopup id="menu_ViewApplyTheme_Popup"
                     datasources="rdf:extensions" ref="urn:mozilla:item:root"
                     oncommand="applyTheme(event.target);" onpopupshowing="checkTheme(this);"
                     sortResource="http://www.mozilla.org/2004/em-rdf#name"
                     sortDirection="ascending">

Bug 391318 comment 8 workaround fixes this ;-|

Dão Gottwald [:dao]

Updated

•

16 years ago

No longer blocks: 472302

Comment 18

•

16 years ago

1) Makes sense that it's something loaded in different mochitest setups, as we're seeing a leak of the same size in other mochichrome as well.
2) There are two workarounds in that comment you cite, which one does help?
3) I wonder why the patch in bug 391318 doesn't help if it's that menu.
4) I wonder why it appeared fixed for some time and then suddenly came up again here.

Reporter

Comment 19

•

16 years ago

Dao, why did you remove bug 472302 dependency, as (for whatever reason) it seems this is what triggered this leak report ?


(In reply to comment #18)
> 1) Makes sense that it's something loaded in different mochitest setups, as
> we're seeing a leak of the same size in other mochichrome as well.

Fwiw, the Browser(Chrome) leak is bug 470709.

> 2) There are two workarounds in that comment you cite, which one does help?

|datasources="rdf:local-store"|, at least.

> 3) I wonder why the patch in bug 391318 doesn't help if it's that menu.
> 4) I wonder why it appeared fixed for some time and then suddenly came up again
> here.

(Me too: I have no idea, on both points.)

Depends on: 391318

Dão Gottwald [:dao]

Comment 20

•

15 years ago

(In reply to comment #19)
> Dao, why did you remove bug 472302 dependency, as (for whatever reason) it
> seems this is what triggered this leak report ?

Given comment 17, bug 472302 doesn't even seem like a useful reference. Even if it triggered a new variant in a chaotic way, the actual bug doesn't seem to be new at all, and I don't think there's anything that we should do in the code that was touched in bug 472302.

Reporter

Comment 21

•

15 years ago

(In reply to comment #14)
> http://hg.mozilla.org/build/buildbot-configs/rev/5fe4bc6513e5

Ftr, the 8 bytes leak was bug 458781.

Reporter

Comment 22

•

15 years ago

[Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9.2a1pre) Gecko/20090228 SeaMonkey/2.0b1pre] (experimental/_m-c_, home, optim default) (W2Ksp4)
(http://hg.mozilla.org/mozilla-central/rev/f7f62131998d
 +http://hg.mozilla.org/comm-central/rev/7ea34ef19dc4)

(Bug still there.)

Reporter

Updated

•

15 years ago

Depends on: 243894

Comment 23

•

15 years ago

Fixed by the patch in bug 470709, therefore marking as dupe.

Status: NEW → RESOLVED

Closed: 15 years ago

Resolution: --- → DUPLICATE