Project

General

Profile

Support #24392

Mismatched free() / delete / delete [] in removeCachedProduct()?

Added by Tingjun Yang about 2 months ago. Updated about 1 month ago.

Status:
Work in progress
Priority:
Normal
Assignee:
-
Target version:
-
Start date:
05/09/2020
Due date:
% Done:

0%

Estimated time:
Scope:
Internal
Experiment:
-
SSI Package:
Co-Assignees:
Duration:

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

Related to artdaq - Support #24439: Use new[] with align parameter in QuickVec to silence Valgrind error in ROOTNew05/19/2020

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


Also available in: Atom PDF