Support #24392
Mismatched free() / delete / delete [] in removeCachedProduct()?
0%
Description
I got the following warning when running decoder on ProtoDUNE data:
==31294== Mismatched free() / delete / delete [] ==31294== at 0x4C2AF2D: free (vg_replace_malloc.c:530) ==31294== by 0x2BC48C49: artdaq::QuickVec<unsigned long long>::~QuickVec() (QuickVec.hh:368) ==31294== by 0x2BC4C61F: artdaq::Fragment::~Fragment() (Fragment.hh:85) ==31294== by 0x3EBCE7E4: void std::_Destroy<artdaq::Fragment>(artdaq::Fragment*) (stl_construct.h:98) ==31294== by 0x3EBCC1B2: void std::_Destroy_aux<false>::__destroy<artdaq::Fragment*>(artdaq::Fragment*, artdaq::Fragment*) (stl_construct.h:108) ==31294== by 0x3EBC8457: void std::_Destroy<artdaq::Fragment*>(artdaq::Fragment*, artdaq::Fragment*) (stl_construct.h:137) ==31294== by 0x3EBC287A: void std::_Destroy<artdaq::Fragment*, artdaq::Fragment>(artdaq::Fragment*, artdaq::Fragment*, std::allocator<artdaq::Fragment>&) (stl_construct.h:206) ==31294== by 0x3EBBD2EA: std::vector<artdaq::Fragment, std::allocator<artdaq::Fragment> >::~vector() (stl_vector.h:567) ==31294== by 0x726C04E9: art::Wrapper<std::vector<artdaq::Fragment, std::allocator<artdaq::Fragment> > >::~Wrapper() (Wrapper.h:86) ==31294== by 0x726C0511: art::Wrapper<std::vector<artdaq::Fragment, std::allocator<artdaq::Fragment> > >::~Wrapper() (Wrapper.h:86) ==31294== by 0x66E3FDF: art::Group::removeCachedProduct() (Group.cc:198) ==31294== by 0x66ECC04: art::Principal::removeCachedProduct(art::ProductID) const (Principal.cc:445) ==31294== Address 0x6e95e5f0 is 0 bytes inside a block of size 784,696 alloc'd ==31294== at 0x4C2AAF8: operator new[](unsigned long) (vg_replace_malloc.c:423) ==31294== by 0x13875EBE: int TStreamerInfo::ReadBuffer<char**>(TBuffer&, char** const&, TStreamerInfo::TCompInfo* const*, int, int, int, int, int) (TStreamerInfoReadBuffer.cxx:970) ==31294== by 0x137169BB: TStreamerInfoActions::VectorLooper::GenericRead(TBuffer&, void*, void const*, TStreamerInfoActions::TLoopConfiguration const*, TStreamerInfoActions::TConfiguration const*) (TStreamerInfoActions.cxx:1858) ==31294== by 0x136234CD: TStreamerInfoActions::TConfiguredAction::operator()(TBuffer&, void*, void const*, TStreamerInfoActions::TLoopConfiguration const*) const (TStreamerInfoActions.h:132) ==31294== by 0x13621637: TBufferFile::ApplySequence(TStreamerInfoActions::TActionSequence const&, void*, void*) (TBufferFile.cxx:3630) ==31294== by 0x1524BBD0: TBranchElement::ReadLeavesCollectionMember(TBuffer&) (TBranchElement.cxx:4344) ==31294== by 0x152324DA: TBranch::GetEntry(long long, int) (TBranch.cxx:1627) ==31294== by 0x15245458: TBranchElement::GetEntry(long long, int) (TBranchElement.cxx:2686) ==31294== by 0x15245023: TBranchElement::GetEntry(long long, int) (TBranchElement.cxx:2630) ==31294== by 0x15245023: TBranchElement::GetEntry(long long, int) (TBranchElement.cxx:2630) ==31294== by 0x1A9B5DA5: art::input::getEntry(TBranch*, long long) (getEntry.cc:24) ==31294== by 0x1A9B5F08: art::input::getEntry(TBranch*, long long, unsigned long long&) (getEntry.cc:37) ==31294==
This may not be a real issue. Just want to be sure.
Related issues
History
#1 Updated by Kyle Knoepfel about 2 months ago
- Scope set to Internal
- Project changed from LArSoft to cet-is
- Tracker changed from Bug to Support
#2 Updated by Kyle Knoepfel about 2 months ago
- Status changed from New to Feedback
Philippe, we've seen this issue before. My recollection is that because ROOT allocates memory using new when reading an object in a ROOT file, valgrind emits a warning for objects that call free in their destructors. The upshot, though, is that this is an innocuous warning. Is that correct?
#3 Updated by Philippe Canal about 2 months ago
Unless there is a very strong reason why not (then it ought to be documented), I recommend that quickVec use 'new char[]' and 'delete []' rather than malloc/free.
Leaving as-is is probably okay but it is still "undefined" behavior.
#4 Updated by Ron Rechenmacher about 1 month ago
Yes, it should have been documented. Our binary output module supports O_DIRECT which necessitates the 512-byte alignment (we use by default). I'll make an issue to document it.
#5 Updated by Philippe Canal about 1 month ago
If you are using C++17, you can now use operator new with alignment (See https://en.cppreference.com/w/cpp/memory/new/operator_new)
#6 Updated by Eric Flumerfelt about 1 month ago
Unfortunately, for now we are still supporting e15 for ProtoDUNE. This should only last until June or so, then we can revisit this issue. I have opened Issue #24439 against artdaq to track this change.
#7 Updated by Kyle Knoepfel about 1 month ago
- Status changed from Feedback to Work in progress
We will leave this open until issue #24439 is addressed.
#8 Updated by Kyle Knoepfel about 1 month ago
- Related to Support #24439: Use new[] with align parameter in QuickVec to silence Valgrind error in ROOT added