Closed Bug 410291 Opened 13 years ago Closed 8 years ago

Windows working set / private bytes regression on 12/29 (suspect bug 399587)

Categories

(Core :: XPConnect, defect, P1)

x86
Windows XP
defect

Tracking

()

RESOLVED WORKSFORME
mozilla1.9.1

People

(Reporter: sayrer, Assigned: mrbkap)

References

()

Details

(Keywords: memory-footprint, regression)

Visible on the tinderbox talos machines.

Looks like mrbkap is the only one in the checkin window, so assigning to him.
Flags: blocking1.9?
OS: Mac OS X → Windows XP
Summary: Windows working set / private bytes regression on 12/20. → Windows working set / private bytes regression on 12/29.
Version: unspecified → Trunk
huh, I don't see how either of those patches could have increased the working set so much without leaking. I'll look into it as soon as I can.
We should figure this out one way or the other - +ing
Flags: blocking1.9? → blocking1.9+
Priority: -- → P2
Blocks: 399587
Depends on: 410223
I noticed this when looking at the graphs to see what jemalloc had brought us, and was a little shocked to see that we haven't brought it back down.

cc'ing stuart who might have some ideas

Seems to have been caused by mrbkap's checkin of bug 399587, which was then backed out by jruderman, and then checked back in after mrbkap fixed bug 410323. When it went back in, the regression returned. It's been there ever since.
Priority: P2 → P1
Target Milestone: --- → mozilla1.9beta4
Summary: Windows working set / private bytes regression on 12/29. → Windows working set / private bytes regression on 12/29 (suspect bug 399587)
Oh, nevermind, I should have checked the dependencies, looks like the fix is in bug 410223.
Now that bug 410223 has been checked in, we should keep an eye on these numbers to see if they go back down.
The regression is still there, on XP talos.
Assignee: mrbkap → honzab
How bad was the regression here? Bkap is pretty swamped with security fixes so there's a good chance we won't get this fixed for release unless we think this is stop-ship bad. Does anyone remember a percentage?
From Blake:

"I have one idea left on this and am trying to figure out the easiest way to implement it -- after that, I have no clue how or why the original patch could have caused (such a large) private bytes regression."

So I guess lets try that one before pushing the panic button. An alternative strategy would be to try to do it in a dot release, but it's scary to punt something without knowing how risky the fix would be.
Priority: P1 → P2
Target Milestone: mozilla1.9beta4 → mozilla1.9
Flags: tracking1.9+ → blocking1.9+
Assignee: honzab → mrbkap
Line 527 in XPCCrossOriginWrapper looks suspicious.

<a href="http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/js/src/xpconnect/src/XPCCrossOriginWrapper.cpp&rev=&cvsroot=/cvsroot#527">http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/js/src/xpconnect/src/XPCCrossOriginWrapper.cpp&rev=&cvsroot=/cvsroot#527</a>

I noticed that XPCWrappedNativeScope::mWrapperMap is not inspected by the cycle collector.
(In reply to comment #10)
> Line 527 in XPCCrossOriginWrapper looks suspicious.
> 
> <a
> href="http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/js/src/xpconnect/src/XPCCrossOriginWrapper.cpp&rev=&cvsroot=/cvsroot#527">http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/js/src/xpconnect/src/XPCCrossOriginWrapper.cpp&rev=&cvsroot=/cvsroot#527</a>
> 
> I noticed that XPCWrappedNativeScope::mWrapperMap is not inspected by the cycle
> collector.
> 

Easy to remedy?
Sayre, if you have ideas for a patch it'd be great to have to try out. Blake is very short on time these days what with finals and such.
Not blocking on this bug, but we'd still love a fix...
Flags: wanted1.9.0.x+
Flags: blocking1.9-
Flags: blocking1.9+
Priority: P2 → P1
(In reply to comment #13)
> Not blocking on this bug, but we'd still love a fix...
> 

Er - why?
Because we have more important bugs to fix. *I* (nor Jonas) wouldn't not hold the release for this. If you disagree, please plus/renom this again.
renominating for blocking based on comment 10

Someone at least needs to look at this...
Flags: blocking1.9.2?
Flags: blocking1.9.1?
Target Milestone: mozilla1.9 → mozilla1.9.1
Not blocking the release on this, but it'd be great to know where to go here...
Flags: blocking1.9.1? → blocking1.9.1-
Flags: wanted1.9.2+
Flags: blocking1.9.2?
Flags: blocking1.9.2-
This has almost certainly been fixed in the meantime.
Status: NEW → RESOLVED
Closed: 8 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.