search

ChimeraTK / ControlSystemAdapter

An adapter layer which allows to use control applications with different control system software environments.
GNU Lesser General Public License v3.0
3 stars 2 forks source link

Adress Sanitizer is reporting a memory leak #31

Closed killenb closed 4 years ago

killenb commented 4 years ago

The address sanitizer in jenkins is reporting a memory leak. Please check and resolve.

jhktimm commented 4 years ago

The leak was detected in ChimeraTK-ControlSystemAdapter-Analysis #613 based on the ChimeraTK-ControlSystemAdapter #995. With ChimeraTK-ControlSystemAdapter #996 the leak is gone. ChimeraTK-ControlSystemAdapter-Analysis #614 is based on ChimeraTK-ControlSystemAdapter #999 still without a leak.

jhktimm commented 4 years ago

================================================================= ==2363==ERROR: LeakSanitizer: detected memory leaks

Direct leak of 128 byte(s) in 2 object(s) allocated from:

0 0x6ebfe2 in operator new(unsigned long) (/scratch/build-ChimeraTK-ControlSystemAdapter/testPVManager+0x6ebfe2)

#1 0x918ba3 in __gnu_cxx::new_allocator<boost::lockfree::queue<ChimeraTK::PVManager::ControlSystemSendNotificationListenerImpl*, boost::parameter::void_, boost::parameter::void_, boost::parameter::void_>::node>::allocate(unsigned long, void const*) /usr/bin/../lib/gcc/x86_64-linux-gnu/5.4.0/../../../../include/c++/5.4.0/ext/new_allocator.h:104:27
#2 0x918ba3 in void boost::lockfree::detail::freelist_stack<boost::lockfree::queue<ChimeraTK::PVManager::ControlSystemSendNotificationListenerImpl*, boost::parameter::void_, boost::parameter::void_, boost::parameter::void_>::node, std::allocator<boost::lockfree::queue<ChimeraTK::PVManager::ControlSystemSendNotificationListenerImpl*, boost::parameter::void_, boost::parameter::void_, boost::parameter::void_>::node> >::reserve<false>(unsigned long) /usr/include/boost/lockfree/detail/freelist.hpp:70

Direct leak of 64 byte(s) in 1 object(s) allocated from:

0 0x6ebfe2 in operator new(unsigned long) (/scratch/build-ChimeraTK-ControlSystemAdapter/testPVManager+0x6ebfe2)

#1 0x91c593 in __gnu_cxx::new_allocator<boost::lockfree::queue<ChimeraTK::PVManager::DeviceSendNotificationListenerImpl*, boost::parameter::void_, boost::parameter::void_, boost::parameter::void_>::node>::allocate(unsigned long, void const*) /usr/bin/../lib/gcc/x86_64-linux-gnu/5.4.0/../../../../include/c++/5.4.0/ext/new_allocator.h:104:27
#2 0x91c593 in void boost::lockfree::detail::freelist_stack<boost::lockfree::queue<ChimeraTK::PVManager::DeviceSendNotificationListenerImpl*, boost::parameter::void_, boost::parameter::void_, boost::parameter::void_>::node, std::allocator<boost::lockfree::queue<ChimeraTK::PVManager::DeviceSendNotificationListenerImpl*, boost::parameter::void_, boost::parameter::void_, boost::parameter::void_>::node> >::reserve<false>(unsigned long) /usr/include/boost/lockfree/detail/freelist.hpp:70
jhktimm commented 4 years ago

Now i am using boost::thread_guard<> to join the thread if joinable when destroyed.

But maybe the problem is in PVManager.h, there are boost::lockfree::queue<DeviceSendNotificationListenerImpl*> _controlSystemNotificationQueue;

killenb commented 4 years ago

I think you found the issue. I guess the solution is still not 100 % clean because the tread is still alive after the pv-Manager is already out of scope. I will quickly fix that.

killenb commented 4 years ago

Wow, I noticed that the whole callable is out of already scope when used. Maybe it's already ok because the callable is copied into the thread. But better safe than sorry.