Project

General

Profile

Support #24392

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

Added by Tingjun Yang 12 months ago. Updated 11 months 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 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

Also available in: Atom PDF