Re: [Inkscape-tracker] [ inkscape-Bugs-1116480 ] eat memory with patterns
On Mon, 2005-06-27 at 11:48 +0200, Ralf Stephan wrote:
(Also the symptoms -- amount of leakage being related to screen area -- are consistent with leaking bitmap memory, which we never allocate with the collector.)
As said before, 20% is here:
The question is, why isn't that 20% being collected?
The most obvious thing would be that, since the XML nodes are also refcounted (via Inkscape::GC::Anchored), that there is either:
1) improper refcounting by SPObjects which reference the XML nodes
2) SPObjects being leaked while they still reference XML nodes
Either one would result in pinning the XML nodes so they could not be collected by the collector.
There are also other, more esoteric possibilities (but those wouldn't generally be so consistent).
If it were #1, you could expect to see most (rather than a smaller percentage) of the leaked memory coming from the GC heap.
Since we are seeing a lot of leaked memory from conventional malloc(), that tends to suggest that garbage-collected memory is being pinned by references from the leaked conventional objects -- i.e. scenario #2.
-mental
As said before, 20% is here:
The question is, why isn't that 20% being collected?
I think I made not clear enough that valgrind will mark everything allocated via operator new(unsigned, Inkscape::GC::ScanPolicy... ) as a leak because no one writes corresponding deletes for that. This does not tell anything about if it actually leaks when the Boehm GC is enabled.
Your statement on the tracker item was that you were surprised that I saw no leak outside the GC. My strategy to show that there is at least some of the huge memory increase due to allocation through the GC was that I looked at what valgrind describes as leak (but really is GC-allocated), and indeed a part of that grew with the overall increase. That part is what I mailed you the backtrace of.
Since we are seeing a lot of leaked memory from conventional malloc(),
I cannot comment on the 80% not GC-allocated but valgrind does not tell me about it. You mention it would be leaking bitmap memory. Why wouldn't valgrind show that? Can you explain?
Regards, ralf
Quoting Ralf Stephan <ralf@...748...>:
My strategy to show that there is at least some of the huge memory increase due to allocation through the GC was that I looked at what valgrind describes as leak (but really is GC-allocated), and indeed a part of that grew with the overall increase. That part is what I mailed you the backtrace of.
Ok... I guess I'm just unclear on where we're going with this. It does suggest that the leaks are of higher-level objects, rather than leaking image buffers directly.
It might be worthwhile to audit the refcounting of NRArenaItems done by the patterns code. Remember that NRArenaItems start with an initial refcount of one, so unless a pointer is retained locally, there ought to be a balacing unref somewhere near where one is created.
Since we are seeing a lot of leaked memory from conventional
malloc(),
I cannot comment on the 80% not GC-allocated but valgrind does not tell me about it. You mention it would be leaking bitmap memory. Why wouldn't valgrind show that? Can you explain?
I can't. Valgrind really should report any memory still unfreed at the time the process exits. Maybe that memory is finally getting freed at final shutdown, but I don't see how...
-mental
participants (3)
-
unknown＠example.com -
MenTaLguY -
Ralf Stephan