valgrind: memleak when sidebar open in writer on close
==3768== 512 bytes in 1 blocks are possibly lost in loss record 25,532 of 28,010 ==3768== at 0x4A06965: operator new(unsigned long) (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so) ==3768== by 0xB52FA41: __gnu_cxx::new_allocator<bool>::allocate(unsigned long, void const*) (new_allocator.h:104) ==3768== by 0xB52EC00: std::__cxx1998::_Deque_base<bool, std::allocator<bool> >::_M_allocate_node() (stl_deque.h:533) ==3768== by 0xB52DE4E: std::__cxx1998::_Deque_base<bool, std::allocator<bool> >::_M_create_nodes(bool**, bool**) (stl_deque.h:627) ==3768== by 0xB52C624: std::__cxx1998::_Deque_base<bool, std::allocator<bool> >::_M_initialize_map(unsigned long) (stl_deque.h:601) ==3768== by 0xB52ACA0: std::__cxx1998::_Deque_base<bool, std::allocator<bool> >::_Deque_base(std::allocator<bool> const&, unsigned long) (stl_deque.h:461) ==3768== by 0xB5296D3: std::__cxx1998::deque<bool, std::allocator<bool> >::deque(std::allocator<bool> const&) (stl_deque.h:791) ==3768== by 0xB52840E: std::__debug::deque<bool, std::allocator<bool> >::deque(std::allocator<bool> const&) (deque:73) ==3768== by 0xB52786B: framework::UndoManagerHelper_Impl::UndoManagerHelper_Impl(framework::IUndoManagerImplementation&) (undomanagerhelper.cxx:221) ==3768== by 0xB525882: framework::UndoManagerHelper::UndoManagerHelper(framework::IUndoManagerImplementation&) (undomanagerhelper.cxx:879) ==3768== by 0x6872683: sfx2::DocumentUndoManager_Impl::DocumentUndoManager_Impl(sfx2::DocumentUndoManager&) (docundomanager.cxx:88) ==3768== by 0x6870FB6: sfx2::DocumentUndoManager::DocumentUndoManager(SfxBaseModel&) (docundomanager.cxx:227) ==3768== by 0x687A272: SfxBaseModel::getUndoManager() (sfxbasemodel.cxx:1677) ==3768== by 0x260E562A: (anonymous namespace)::getUndoManager(com::sun::star::uno::Reference<com::sun::star::frame::XFrame> const&) (PagePropertyPanel.cxx:74) ==3768== by 0x260E6C60: sw::sidebar::PagePropertyPanel::PagePropertyPanel(Window*, com::sun::star::uno::Reference<com::sun::star::frame::XFrame> const&, SfxBindings*) (PagePropertyPanel.cxx:189) ==3768== by 0x260E593C: sw::sidebar::PagePropertyPanel::Create(Window*, com::sun::star::uno::Reference<com::sun::star::frame::XFrame> const&, SfxBindings*) (PagePropertyPanel.cxx:101) The SfxBaseModel creates the DocumentUndoManager on demand at sfx2/source/doc/sfxbasemodel.cxx:1685 m_pDocumentUndoManager is a rtl::Reference but debugging into the acquire/release I see that the DocumentUndoManager::acquire/DocumentUndoManager::release forward to those of SfxModelSubComponent which forward them to its rModel without doing anything else, so the implementations of DocumentUndoManager::acquire/DocumentUndoManager::release don't actually do anything directly to the DocumentUndoManager itself so there is nothing that will really release it. Either the rModel needs to explicitly destroy it somehow, given that the acquire/release delegate responsibility to it, or the whole thing is addled. I rather feel it's addled, so implement as a normal WeakImplHelper1, but cowardly in addition also keep acquire/release on the rModel. Change-Id: Ib52544a9276fd8d9d489ad6b6afda12498cc39fa
Showing
Please
register
or
sign in
to comment