search for: enable_shared_from_thi

Hello, I just discovered, that, when using enable_shared_from_this and inheriting it privately, this fails at runtime. I made a small example: #include <memory> #include <boost/shared_ptr.hpp> #include <boost/make_shared.hpp> #include <boost/enable_shared_from_this.hpp> #ifndef prefix #define prefix std #endif class foo: prefix::e...

Am 29.08.19 um 12:07 schrieb Jonathan Wakely: > On Thu, 29 Aug 2019 at 10:15, Christian Schneider > <cschneider at radiodata.biz> wrote: >> >> Hello, >> I just discovered, that, when using enable_shared_from_this and >> inheriting it privately, this fails at runtime. >> I made a small example: >> >> #include <memory> >> #include <boost/shared_ptr.hpp> >> #include <boost/make_shared.hpp> >> #include <boost/enable_shared_from_this.hpp> >&gt...

...; 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))​ > pbqp_leak.diff > <https://docs.google.com/file/d/0B0jpkch...

Hi Lang, In PBQPBuilderWithCoalescing::build, around line 360, we have code looking like: … PBQP::Vector newCosts(g.getNodeCosts(node)); addPhysRegCoalesce(newCosts, pregOpt, cBenefit); g.setNodeCosts(node, newCosts); … I suspect the leak occurs around the setNodeCosts method, and I have trouble understanding how it handles the case where the node already has costs. It seems to