463263 - leaking nsHostResolver a lot on multiple platforms from unrelated checkins

Status: RESOLVED FIXED

(Core :: General, defect)

Description

[Dietrich Ayala (:dietrich)]

requesting blocking due to the amount of noisy orange created on the tree. assigning to patrick per bz's request.

Comment 1

[Patrick McManus [:mcmanus]]

Dietrich, I'm not that familiar with all the lingo. Can you point me to the test/description/data/recreate for this so I can address your specific problem?

Comment 2

[Dietrich Ayala (:dietrich)]

Hi Patrick, the problem is visible on the tinderbox:

http://tinderbox.mozilla.org/showbuilds.cgi?tree=Firefox

The orange builds between 8 and 10am PST are largely due to leaks, as shown in this log:

http://tinderbox.mozilla.org/showlog.cgi?log=Firefox/1225911799.1225912078.20218.gz

(search for nsHostResolver)

The checkins at the time are not likely to have caused the leak. Boris said you knew about the problem, and could address it.

Comment 3

[Karl Tomlinson (:karlt)]

--ALL-LEAKS-----------------------------------leaks------leaks%-----------------------
TOTAL                                           368       0.00%
nsHostResolver                                  140       0.00%
nsDNSAsyncRequest                                96       0.00%
nsHostRecord                                     60       0.00%
nsHTMLDNSPrefetch                                56       0.00%
nsStringBuffer                                   16       0.00%

Comment 4

[Karl Tomlinson (:karlt)]

There is some info on leak test tools here:
https://developer.mozilla.org/en/Debugging_memory_leaks
and sparser info here:
https://wiki.mozilla.org/Performance:Leak_Tools

I find that looking at the commands in the tinderbox log gives the best documentation on which commands are useful.

Comment 5

[Patrick McManus [:mcmanus]]

Thanks for the background karl and dietrich.. I'll look into it now. The problem is no doubt with code I wrote that impacts those classes and was just checked in, but I don't at this time know specifically what is causing the problem.

Comment 6

[Justin Dolske [:Dolske]]

Patrick: Which bug/checkin caused this? If there's not a obvious cause (and thus fix), we should back it out while it's investigated.

Comment 7

[Justin Dolske [:Dolske]]

I'm assuming one of these was the cause:

19b3caf108d1	Boris Zbarsky — Bug 453403. Fix leak of nsHostResolver by making
                  sure to wake up all the worker threads on shutdown
e8fd3f4c52b6	Patrick McManus — Bug 453403. Add DNS prefetching, similar to
                  what Google chrome does. r+sr=bzbarsky
39fd2b88d622	Patrick McManus — Bug 459724. Make page reload bypass the DNS
                  cache. r+sr=bzbarsky
4542793088dc	Patrick McManus — Bug 459724. Fix normalization of flags in the
                  DNS cache to allow other work that depends on these flags to
                  happen. r+sr=bzbarsky

I'm going to back them all out.

Comment 8

[Patrick McManus [:mcmanus]]

justin - no doubt contained in he first two (and they should be applied and removed together).

Comment 9

[Justin Dolske [:Dolske]]

Ok, backed out 19b3caf108d1 and e8fd3f4c52b6 (for bug 453403). As long as things stay green, the other two changesets (for bug 459724) can stay.

Comment 10

[Steven Michaud [:smichaud] (Retired)]

See also bug 462410.

Comment 11

[Justin Dolske [:Dolske]]

This seems to have fixed the problem at hand.

Comment 12

[Boris Zbarsky [:bzbarsky]]

> See also bug 462410.

That doesn't seem related (in particular, it predates these leak fixes).