You’re right: newCosts should be a copy of the node’s costs, as it may be modified. When we call setNodeCost’s, the PBQP::Vector’s assignment operator should free the old costs, but I may have misimplemented that (or forgotten it entirely).
Out of interest - what makes you suspect the vector cost changes, rather than the matrix ones? Is the tool indicating a leak due to those lines?
The memory operations for the vector costs should be fairly straightforward, but the matrix operations use a value-pool system behind the scenes to reduce the PBQP allocator’s memory overhead. The extra complexity of that makes it a prime suspect for memory leaks.
While I’m not sure where the leak is, using some pre-canned memory management might help…
Attached is a patch that changes this allocation to use shared_ptr, perhaps it’ll address the bug?
(ideally we shouldn’t need the intrusive ref counting (std::enable_shared_from_this) but instead have a weak_set that has std::weak_ptr in it & implicitly removes elements as they become null (probably on a harvesting schedule, rather than with a direct callback as is currently implemented))
Oooh. Neat. Thanks Dave. Please go ahead and commit that.
Committed in 217563.
Running the PBQP test without my change under valgrind didn't show any
memory leak, but hopefully with Arnaud's change and valgrind he can see the
leak and then verify that my change addresses it... *fingers crossed*
Excellent. Thanks again Dave. And thanks for the testing Arnaud.
For the curious: I went back to look for the leak and it’s obvious with hindsight. PoolRef’s destructor was deleting the PoolEntry when the ref-count hit zero, but the assignment operator was not. This was an oversight left over from when I moved responsibility for deleting PoolEntries from PoolEntry itself out to PoolRef. It’s all moot now though: Dave’s solution fixes this, and is much cleaner to boot.