[MOAB-dev] memory leak in AEntityFactory.cpp

[Vijay S. Mahadevan]

Hi Lukasz,

Thanks for raising this issue.

> In case of not the case (true == both_ways && to_type != MBVERTEX), or result != MB_SUCESS, should we realise adj_list_ptr. I can do PR,  if needed.

Yes, this is correct. We should release the memory in the else block.
We would appreciate a PR so that this can be quickly reviewed and
merged. Although a much cleaner option would be to actually not use
the pointer allocation here for adj_list_ptr at all. I'll need to look
at the code/call stack more closely to see if this would have any side
effects.

FYI, we are preparing for a new release by end of the week and so
would be good to get this resolved soon.

Thanks,
Vijay

On Mon, May 18, 2020 at 8:46 AM Lukasz Kaczmarczyk
<Lukasz.Kaczmarczyk at glasgow.ac.uk> wrote:
>
> Hello,
>
> I encounter following leak,
>
> ==2639== 40,680 bytes in 5,085 blocks are indirectly lost in loss record 62 of 63
> ==2639==    at 0x4837DBF: operator new(unsigned long) (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
> ==2639==    by 0x4EA49CB: __gnu_cxx::new_allocator<unsigned long>::allocate(unsigned long, void const*) (new_allocator.h:111)
> ==2639==    by 0x4E90C2B: std::allocator_traits<std::allocator<unsigned long> >::allocate(std::allocator<unsigned long>&, unsigned long) (alloc_traits.h:436)
> ==2639==    by 0x4E75AB7: std::_Vector_base<unsigned long, std::allocator<unsigned long> >::_M_allocate(unsigned long) (stl_vector.h:296)
> ==2639==    by 0x4FF60A4: void std::vector<unsigned long, std::allocator<unsigned long> >::_M_realloc_insert<unsigned long const&>(__gnu_cxx::__normal_iterator<unsigned long*, std::vector<unsigned long, std::allocator<unsigned long> > >, unsigned long const&) (vector.tcc:427)
> ==2639==    by 0x8652FCC: push_back (stl_vector.h:1085)
> ==2639==    by 0x8652FCC: moab::AEntityFactory::add_adjacency(unsigned long, unsigned long, bool) (AEntityFactory.cpp:393)
> ==2639==    by 0x8736ED5: ranged_insert_entities (MeshSet.cpp:613)
> ==2639==    by 0x8736ED5: moab::MeshSet::insert_entity_ranges(moab::Range const&, unsigned long, moab::AEntityFactory*) (MeshSet.cpp:985)
> ==2639==    by 0x89A2FDF: moab::ReadHDF5::read_set_data(moab::Range const&, unsigned long, moab::ReadHDF5Dataset&, moab::ReadHDF5::SetMode, moab::Range*) (ReadHDF5.cpp:2568)
> ==2639==    by 0x89B33FF: moab::ReadHDF5::read_sets(moab::Range const&) (ReadHDF5.cpp:1958)
> ==2639==    by 0x89B6FF9: moab::ReadHDF5::load_file_impl(moab::FileOptions const&) (ReadHDF5.cpp:647)
> ==2639==    by 0x89B7662: moab::ReadHDF5::load_file(char const*, unsigned long const*, moab::FileOptions const&, moab::ReaderIface::SubsetList const*, moab::TagInfo* const*) (ReadHDF5.cpp:555)
> ==2639==    by 0x86842B9: moab::Core::serial_load_file(char const*, unsigned long const*, moab::FileOptions const&, moab::ReaderIface::SubsetList const*, moab::TagInfo* const*) (Core.cpp:600)
> ==2639==
> ==2639== 162,720 (122,040 direct, 40,680 indirect) bytes in 5,085 blocks are definitely lost in loss record 63 of 63
> ==2639==    at 0x4837DBF: operator new(unsigned long) (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
> ==2639==    by 0x8652639: moab::AEntityFactory::get_adjacencies(unsigned long, std::vector<unsigned long, std::allocator<unsigned long> >*&, bool) (AEntityFactory.cpp:565)
> ==2639==    by 0x8652EB5: moab::AEntityFactory::add_adjacency(unsigned long, unsigned long, bool) (AEntityFactory.cpp:376)
> ==2639==    by 0x8736ED5: ranged_insert_entities (MeshSet.cpp:613)
> ==2639==    by 0x8736ED5: moab::MeshSet::insert_entity_ranges(moab::Range const&, unsigned long, moab::AEntityFactory*) (MeshSet.cpp:985)
> ==2639==    by 0x89A2FDF: moab::ReadHDF5::read_set_data(moab::Range const&, unsigned long, moab::ReadHDF5Dataset&, moab::ReadHDF5::SetMode, moab::Range*) (ReadHDF5.cpp:2568)
> ==2639==    by 0x89B33FF: moab::ReadHDF5::read_sets(moab::Range const&) (ReadHDF5.cpp:1958)
> ==2639==    by 0x89B6FF9: moab::ReadHDF5::load_file_impl(moab::FileOptions const&) (ReadHDF5.cpp:647)
> ==2639==    by 0x89B7662: moab::ReadHDF5::load_file(char const*, unsigned long const*, moab::FileOptions const&, moab::ReaderIface::SubsetList const*, moab::TagInfo* const*) (ReadHDF5.cpp:555)
> ==2639==    by 0x86842B9: moab::Core::serial_load_file(char const*, unsigned long const*, moab::FileOptions const&, moab::ReaderIface::SubsetList const*, moab::TagInfo* const*) (Core.cpp:600)
> ==2639==    by 0x8684E57: moab::Core::load_file(char const*, unsigned long const*, char const*, char const*, int const*, int) (Core.cpp:514)
> ==2639==    by 0x4FB5E37: FractureMechanics::MWLSApprox::loadMWLSMesh(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >) (MWLS.cpp:100)
> ==2639==    by 0x1A5FE4: main (mwls_at_gauss_point.cpp:166)
>
> In following function,
>
> ErrorCode AEntityFactory::add_adjacency(EntityHandle from_ent,
>                                            EntityHandle to_ent,
>                                            const bool both_ways)
> {
>   EntityType to_type = TYPE_FROM_HANDLE(to_ent);
>
>   if (to_type == MBVERTEX)
>     return MB_ALREADY_ALLOCATED;
>
>
>
>   AdjacencyVector *adj_list_ptr = NULL;
>   ErrorCode result = get_adjacencies( from_ent, adj_list_ptr, true );
>   if (MB_SUCCESS != result)
>     return result;
>
>     // get an iterator to the right spot in this sorted vector
>   AdjacencyVector::iterator adj_iter;
>   if (!adj_list_ptr->empty())
>   {
>     adj_iter = std::lower_bound(adj_list_ptr->begin(), adj_list_ptr->end(),
>                                 to_ent);
>
>     if ( adj_iter == adj_list_ptr->end() || to_ent != *adj_iter )
>     {
>       adj_list_ptr->insert(adj_iter, to_ent);
>     }
>   }
>   else
>     adj_list_ptr->push_back(to_ent);
>
>     // if both_ways is true, recursively call this function
>   if (true == both_ways && to_type != MBVERTEX)
>     result = add_adjacency(to_ent, from_ent, false);
>
>   return result;
> }
>
> In case of not the case (true == both_ways && to_type != MBVERTEX), or result != MB_SUCESS, should we realise adj_list_ptr. I can do PR,  if needed.
>
>
> Kind regards,
> Lukasz
>