Opening the attached file and F5-ing several times will almost always leak: |<----------------Class--------------->|<-----Bytes------>|<----------------Objects---------------->|<--------------References-------------->| Per-Inst Leaked Total Rem Mean StdDev Total Rem Mean StdDev 0 TOTAL 28 808 482470 15 ( 2601.84 +/- 3868.37) 759640 10 ( 2262.01 +/- 4164.97) 515 nsHashtable 72 72 244 1 ( 121.25 +/- 70.25) 0 0 ( 0.00 +/- 0.00) 603 nsNPAPIPluginInstance 152 152 5 1 ( 1.00 +/- 0.71) 186 2 ( 5.41 +/- 2.00) 604 nsNPAPIPluginStreamListener 136 136 5 1 ( 1.00 +/- 0.71) 14 1 ( 1.63 +/- 0.84) 642 nsPluginStreamListenerPeer 224 224 5 1 ( 1.00 +/- 0.71) 33 1 ( 2.45 +/- 1.15) 701 nsSimpleURI 120 120 93 1 ( 16.16 +/- 9.91) 1976 1 ( 103.59 +/- 54.22) 712 nsStringBuffer 8 32 24684 4 ( 6724.16 +/- 3588.22) 56212 4 (13048.03 +/- 6253.58) 752 nsTArray_base 8 32 74208 4 (10164.40 +/- 3599.51) 0 0 ( 0.00 +/- 0.00) 792 nsVoidArray 8 8 5053 1 ( 1200.34 +/- 648.86) 0 0 ( 0.00 +/- 0.00) 794 nsWeakReference 32 32 216 1 ( 101.67 +/- 56.07) 2125 1 ( 398.57 +/- 203.39) The is similar to bug 766886, but different in that the leaked instance is permanent, rather than a clean-up race on shutdown.

FEAR THE TEST MATRIX!

Must simplified test case that seems to leak 100% of the time

So here's a different test case that triggers this simply: 1) Start a plugin that has a src/data attribute, but *dont* open the stream for it (which we dont for embed tags that have a plugin type) 2) Remove it from the document once it is running 3) Leak This occurs with flash as well as the test plugin. It's probably occurring fairly frequently in the wild, but is fairly small, 808 bytes per plugin leaked.

I believe bug 767633 will fix this

After bug 767633 this no longer reproduces. Bug 783059 will also add test coverage for this (the test there is what caught this)