Merge lp:~jameinel/bzr/2.0.4-494406-serve-memory-leak into lp:bzr/2.0
Proposed by
John A Meinel
Status: | Merged | ||||
---|---|---|---|---|---|
Merged at revision: | not available | ||||
Proposed branch: | lp:~jameinel/bzr/2.0.4-494406-serve-memory-leak | ||||
Merge into: | lp:bzr/2.0 | ||||
Diff against target: |
38 lines (+8/-2) 2 files modified
NEWS (+7/-1) bzrlib/_bencode_pyx.pyx (+1/-1) |
||||
To merge this branch: | bzr merge lp:~jameinel/bzr/2.0.4-494406-serve-memory-leak | ||||
Related bugs: |
|
Reviewer | Review Type | Date Requested | Status |
---|---|---|---|
Andrew Bennetts | Approve | ||
Review via email: mp+16369@code.launchpad.net |
To post a comment you must log in.
I managed to track down the memory leak on server-side operations to bzrlib. bencode. Encoder.
It turns out that Encoder was using '__del__' as its cleanup function, when it should have been '__dealloc__'. I don't know if __del__ ever gets called for Pyrex objects, but I do know that __dealloc__ always gets called. (And doesn't cause problems with GC cycles, as it gets put into the tp_dealloc slot.)
Anyway, this one-line patch gets rid of the memory leak as near as I can tell. (At least cycling on 'bzr commit' no longer leaks memory.)
It could also have a fair impact on codehostings 'lp-serve'. As that would be encoding a *lot* of bytes to send over the wire. This memory was also "dark" memory, in that it was allocated directly using 'malloc()' and thus not seen by Meliae. I'm not positive, but I think for every byte that 'bzr lp-serve' would send over the wire, it would get wrapped by a 'bencode' operation, which means that every byte sent out gets permanently leaked in memory. (Maybe we don't serve bulk data through a bencode wrapper.) At least, all of the response tuples are certainly encoded.
It doesn't affect my 'memory reduction' tests that I used for 2.1.0b3, because those were operating locally.