Closed Bug 409674 Opened 17 years ago Closed 17 years ago

No leak logging for DOM windows or documents

Categories

(Core :: DOM: Core & HTML, defect)

defect
Not set
major

Tracking

()

RESOLVED FIXED
mozilla1.9beta3

People

(Reporter: wgianopoulos, Assigned: wgianopoulos)

References

Details

(Keywords: regression)

Attachments

(1 file)

The checkin for bug 403830 seems to have resulted in bypassing the leak logging for DOM windows and documents. This means that dbaron's leak gauge now only works for docshell leaks.
Flags: blocking1.9?
Can confirm this bug. Don't know if the bug mentioned by Bill caused it or not. Seems serious as I'd like to contribute to leak testing for v3 using leak-gauge.pl
Also, I actually do believe this could be considered a blocker as it halts a major way of testing development of the browser. For instance to see if any new changes to code cause memory leaks.
You can still use trace-refcnt logging, but that takes significantly more time to get working ;)
What's the regression window that led you to bug 403830? I don't see anything in the patch there that would have done this.
(In reply to comment #4) > What's the regression window that led you to bug 403830? I don't see anything > in the patch there that would have done this. > I did a pull by time from the tree specifying 2007-12-15 01:40 -0800. The resultant build worked fine. I then updated the tree to 2007-12-15 02:00 -0800 and that build shows the issue. This is the only check-in between those 2 times.
(In reply to comment #6) > The only 2 checkins are bug 403830 and its subsequent regression fix. ^^^^^^^^^^ bustage
FWIW as well Works: 20071214_2343_firefox-3.0b3pre.en-US.win32 Broken: 20071215_0201_firefox-3.0b3pre.en-US.win32 Checkins to module PhoenixTinderbox between 2007-12-14 23:43 and 2007-12-15 02:00 : http://bonsai.mozilla.org/cvsquery.cgi?module=PhoenixTinderbox&date=explicit&mindate=1197704580&maxdate=1197712859
Oh, the problem looks like that prlog.h is included in nsNodeInfoManager.h. It really shouldn't be included in header files since some users need to define FORCE_PR_LOGGING before including it for the first time. Either that or we need to move the FORCE_PR_LOGGING up to before all the includes -- but that might force on logging done by the nsNodeInfoManager.h header file that we don't want elsewhere.
(In reply to comment #9) > Oh, the problem looks like that prlog.h is included in nsNodeInfoManager.h. It That seems to be exactly the issue. Oddly, just removing the include, seems to resolve the issue, result in no compiler or linker issues and passing all unit tests.
Want to post the patch, or should I (probably later)?
Attached patch patch v1Splinter Review
Assignee: nobody → wgianopoulos
Status: NEW → ASSIGNED
Attachment #294493 - Flags: review?
Attachment #294493 - Flags: review? → review?(dbaron)
Comment on attachment 294493 [details] [diff] [review] patch v1 r+sr=dbaron
Attachment #294493 - Flags: superreview+
Attachment #294493 - Flags: review?(dbaron)
Attachment #294493 - Flags: review+
Comment on attachment 294493 [details] [diff] [review] patch v1 dbaron, can you grant approval, too?
Attachment #294493 - Flags: approval1.9?
Comment on attachment 294493 [details] [diff] [review] patch v1 a=beltzner for 1.9
Attachment #294493 - Flags: approval1.9? → approval1.9+
Checking in content/base/src/nsNodeInfoManager.h; /cvsroot/mozilla/content/base/src/nsNodeInfoManager.h,v <-- nsNodeInfoManager.h new revision: 1.32; previous revision: 1.31 done
Status: ASSIGNED → RESOLVED
Closed: 17 years ago
Keywords: checkin-needed
Resolution: --- → FIXED
Target Milestone: --- → mozilla1.9 M11
Component: DOM → DOM: Core & HTML
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: