860482 - Leak with document navigation, iframes, fragments

Status: NEW

(Core :: DOM: Navigation, defect)

Description

[Jesse Ruderman]

Attachment: testcase (must be local; must be loaded as the first in a tab)

1. XPCOM_MEM_LEAK_LOG=2 firefox nav-leak.html
     (or otherwise load the testcase as the first item in a tab)
2. Quit Firefox

Trace-refcnt reports leaked nsDocShell, nsDocument, nsGlobalWindow.

This seems to be a regression from http://hg.mozilla.org/mozilla-central/rev/b695e94363b5 (bug 825544).  Which is fun because all that did was back out bug 754029 and its followups.  I haven't checked whether the new patch in bug 754029 fixes this leak.

Comment 1

[O. Atsushi (Torisugari)]

Attachment: setTimeout enables us to bypass "data:" URI's same-origin check

(In reply to Jesse Ruderman from comment #0)
> I haven't checked whether the new patch in bug 754029 fixes this leak.

The new one also seem to (superficially) fix the mlk in my tree. However, attachment 735968 [details] contains several problematic factors in addition to mlk.

Is this intended behavior?

Comment 2

[Jesse Ruderman]

I felt the same way.  Why does the final "window.history.back();" cause the entire testcase to reload, rather than just affecting the frame or at most the main doc's hash?

Comment 3

[O. Atsushi (Torisugari)]

(In reply to Jesse Ruderman from comment #2)
> I felt the same way.  Why does the final "window.history.back();" cause the
> entire testcase to reload, rather than just affecting the frame or at most
> the main doc's hash?

Maybe the initial session history entry doesn't have bfcache/scroll-position because loading hasn't finished on #hash change.

Comment 4

[Jesse Ruderman]

My DOM fuzzer will ignore leaks with frames or history until this is fixed.

Comment 5

[Jesse Ruderman]

... except when it outsmarts me, like it did with bug 886213.

Comment 6

[Nicholas Nethercote [inactive]]

Olli, care to take a look? :)

Comment 7

[Olli Pettay [:smaug][[e-mail]]]

(I have been debugging this, but haven't found the cause yet.)

Comment 8

[Jesse Ruderman]

Still leaks on trunk. Prevents me from checking for leaks in testcases that use frames, history, or <object>.

Comment 9

[Andrew McCreight [:mccr8]]

I'm using DMD heap scanning to investigate this. I found the first problem: nsGlobalWindow::mLocation is not reported to the cycle collector. This alone, however, does not fix the leak.

Comment 10

[Andrew McCreight [:mccr8]]

I should look at this again at some point. FWIW, nsGlobalWindowInner::mLocation is now being reported to the CC.

Comment 11

[Andrew McCreight [:mccr8]]

Unfortunately I haven't had time to look at this recently. I'll clear the fuzzblocker tag as I don't think whatever old fuzzing effort that was for is happening anyways.