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 11 months ago
- Scope set to Internal
- Project changed from LArSoft to cet-is
- Tracker changed from Bug to Support
#2 Updated by Kyle Knoepfel 11 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 11 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 11 months 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 11 months 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 11 months 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 11 months ago
- Status changed from Feedback to Work in progress
We will leave this open until issue #24439 is addressed.
#8 Updated by Kyle Knoepfel 11 months ago
- Related to Support #24439: Use new[] with align parameter in QuickVec to silence Valgrind error in ROOT added