Closed Bug 435138 Opened 17 years ago Closed 17 years ago

Strange leak logging behaviors on qm-win2k3-moz2-01 cause perma-orange

Categories

(Release Engineering :: General, defect)

Product:
Release Engineering
Component:
General
Platform:
x86
Windows Server 2003
Type:
defect
Priority:
Not set
Severity:
critical

Tracking

(Not tracked)

Status:
RESOLVED WORKSFORME

People

(Reporter: Waldo, Unassigned)

References

(
URL
)

Details

runtests.py has leak logging which always runs when refcount logging is enabled. This is determined by setting an environment variable, running, and checking for the existence of the file to which logging was to occur. Iff the file exists, leak detection runs. On the win2k3 box, leak logging has gone whack. The log file is being created and written, but something weird is happening with output generation. The file's contents are as follows: == BloatView: ALL (cumulative) LEAK AND BLOAT STATISTICS |<----------------Class--------------->|<-----Bytes------>|<----------------Objects---------------->|<--------------References-------------->| Per-Inst Leaked Total Rem Mean StdDev Total Rem Mean StdDev 0 TOTAL 74 -2147483328 3236 -8 ( 176.89 +/- 225.05) 12287 4 ( 116.67 +/- 82.34) 1 FontEntry 80 80 100 1 ( 50.25 +/- 28.80) 8264 4 ( 162.87 +/- 55.65) 2 FontFamily 28 0 46 0 ( 23.00 +/- 13.36) 1297 0 ( 63.01 +/- 21.09) 3 gfxGlyphExtents 40 -2147483648 0 -12 ( 0.00 +/- 0.00) 0 0 ( 0.00 +/- 0.00) 4 gfxTextRun 80 240 2181 3 ( 259.57 +/- 232.94) 0 0 ( 0.00 +/- 0.00) 5 nsThebesRenderingContext 64 0 909 0 ( 1.50 +/- 0.50) 2726 0 ( 2.17 +/- 0.69) Leaks are detected by running a regular expression over the file to grab the classes that leak and the TOTAL line to determine the total amount leaked. The regex doesn't expect negative numbers for the leak count -- why would it? -- but for whatever reason, it seems that the leak count here is negative! The regex fails to match, so the TOTAL line is never seen, and paranoia-checking logic causes "ERROR FAIL missing output line for total leaks!" to be printed, which causes the tinderbox to go and stay orange. The whack number seems to be entirely due to gfxGlyphExtents in the two logs so far that have this in effect. This effect is entirely confined to this tinderbox -- Mac and Linux have no such problems. It almost looks like something is wrong with the refcount logging code itself, but I've never heard of that happening before. Since this causes perma-orange, we probably have to deal with it before the tinderbox can open, since a perma-orange box is pain for everyone.
Okay, this is whacked. The latest build is green, and the leak logs in it are all perfectly fine, everything recorded correctly. Did something change on the box? Given the times between which the change would have happened, I think it unlikely, but it's possible. Hopefully it'll stay green and we can chalk this up as a WFM.
dbaron made a fix for bug 433708. Related? Might also fix bug 432338?
Perhaps; since that was trace-malloc leak logging and not refcnt logging, it doesn't look like it would have, but I haven't looked at trace-malloc very much and don't know how much they're intertwined.
(In reply to comment #2) > dbaron made a fix for bug 433708. Related? Definitely NOT related. > Might also fix bug 432338? No, that's probably related to bug 433708, but not this.
curiouser and curiouser. As much as I'd like to take credit for it, I don't think I had anything to do with this. I'm happy to close this and mark it WFM or Invalid if nobody objects.
FWIW, I did a Windows build with a private and unimplemented copy-constructor and operator= on gfxGlyphExtents, and it compiled, so the implicit ones weren't the cause of the problem.
not sure. We can chalk it up to new box pain. Marking WFM.
Status: NEW → RESOLVED
Closed: 17 years ago
Resolution: --- → WORKSFORME
Product: mozilla.org → Release Engineering
You need to log in before you can comment on or make changes to this bug.