Closed jbmouret closed 4 years ago
Hi @jbmouret, and thanks for this report and investigation.
I totally agree, we should use more shared_ptr.
I could handle this task, but not soon, so if anyone wants to help a bit on that, this would be really welcome :)
OK, I will put it in my (long) TODO list.
Agreed. When I first implemented TSID I didn't have in mind this use-case, so I didn't take care of deallocating memory. My bad. Unfortunately now that the semester started I'm also very busy, so I don't know when I could find the time to do it. Worst case could be January for me.
@andreadelprete OK. At least I know that there is no secret deallocator :) I will try to work on this and submit a PL.
Is there a reason for not compiling in c++11 ? (14 or 17 would be even better). We do not have shared_ptr in std:: in c++98, except if we use boost.
Since URDFDOM >= 1.0.0, we have to rely on C++11 at the Pinocchio level. So, except if @nim65s or @olivier-stasse or @andreadelprete do not agree, we may go toward std::shared_ptr and C++11. But boost::shared_ptr remains a good candidate I would say.
Until this month, our TALOS was in 16.04 LTS. And by default 16.04 LTS is in C++98. We had several problems with some boost libraries such as boost::variant not behaving nicely when mixing C++98 and C++11. But all of our robots are now at least on 18.04 LTS. So I am fine with C++11.
I've moved all the pointers to shared_ptr and there is no leak anymore! (and yes, this means c++11)
=56088== LEAK SUMMARY:
==56088== definitely lost: 0 bytes in 0 blocks
==56088== indirectly lost: 0 bytes in 0 blocks
==56088== possibly lost: 0 bytes in 0 blocks
https://github.com/resibots/tsid/tree/fix_leaks
I still need to have a look at the python interface, as we usually do not attempt to compile it.
It looks nice. Thanks.
I am fine with the switch to c++11
closed by #112
Hi
It seems that TSID is leaking quite a lot of memory. Valgrind says that for the tests/tsid-formulation:
=> so, about 2Mb for the test (it might look like nothing, but our code create TSID objects about 50-100k times, which means about 100Gb can be lost!
See the full report below. From a quick look, it seems that the tsid formulation calls many new, but no delete (see https://github.com/stack-of-tasks/tsid/blob/master/src/formulations/inverse-dynamics-formulation-acc-force.cpp).
=> is it "normal"? It would not be hard to call delete in the destructor or put everything in shared_ptr, I guess.