Debugging memory allocation/freeing

[Mohammad Ewais]

Hi, I am encountering some segmentation faults in my client. Using GDB I could find stacktraces similar to this:

#0  common_heap_free (tu=0x7ff7662ac0e8, p_void=0x7ff7663a5cf8, size=<optimized out>) at /home/travis/build/DynamoRIO/dynamorio/core/heap.c:4523

#1  0x00007ff82a38c337 in common_global_heap_free (size=140700548750584, p=0x7ff7663a5cf8, tu=<optimized out>) at /home/travis/build/DynamoRIO/dynamorio/core/heap.c:3475

#2  global_heap_free (p=0x7ff7663a5cf8, size=140700548750584) at /home/travis/build/DynamoRIO/dynamorio/core/heap.c:3508

#3  0x00007ff7e696f8b6 in __gnu_cxx::new_allocator<std::_Rb_tree_node<DCS::EVENT::Timing*> >::deallocate (this=0x7ff7e6c46fa0, __p=0x7ff7663a5d00, __t=1) at /usr/include/c++/10/ext/new_allocator.h:133

#4  0x00007ff7e696ef89 in std::allocator<std::_Rb_tree_node<DCS::EVENT::Timing*> >::deallocate (__n=1, __p=0x7ff7663a5d00, this=0x7ff7e6c46fa0) at /usr/include/c++/10/bits/allocator.h:187

#5  std::allocator_traits<std::allocator<std::_Rb_tree_node<DCS::EVENT::Timing*> > >::deallocate (__a=..., __p=0x7ff7663a5d00, __n=1) at /usr/include/c++/10/bits/alloc_traits.h:492

#6  0x00007ff7e696e161 in std::_Rb_tree<DCS::EVENT::Timing*, DCS::EVENT::Timing*, std::_Identity<DCS::EVENT::Timing*>, std::less<DCS::EVENT::Timing*>, std::allocator<DCS::EVENT::Timing*> >::_M_put_node (this=0x7ff7e6c46fa0, __p=0x7ff7663a5d00)

    at /usr/include/c++/10/bits/stl_tree.h:588

#7  0x00007ff7e696ccb4 in std::_Rb_tree<DCS::EVENT::Timing*, DCS::EVENT::Timing*, std::_Identity<DCS::EVENT::Timing*>, std::less<DCS::EVENT::Timing*>, std::allocator<DCS::EVENT::Timing*> >::_M_drop_node (this=0x7ff7e6c46fa0, __p=0x7ff7663a5d00)

    at /usr/include/c++/10/bits/stl_tree.h:655

#8  0x00007ff7e696bd28 in std::_Rb_tree<DCS::EVENT::Timing*, DCS::EVENT::Timing*, std::_Identity<DCS::EVENT::Timing*>, std::less<DCS::EVENT::Timing*>, std::allocator<DCS::EVENT::Timing*> >::_M_erase (this=0x7ff7e6c46fa0, __x=0x7ff7663a5d00)

    at /usr/include/c++/10/bits/stl_tree.h:1921

#9  0x00007ff7e696e540 in std::_Rb_tree<DCS::EVENT::Timing*, DCS::EVENT::Timing*, std::_Identity<DCS::EVENT::Timing*>, std::less<DCS::EVENT::Timing*>, std::allocator<DCS::EVENT::Timing*> >::clear (this=0x7ff7e6c46fa0)

    at /usr/include/c++/10/bits/stl_tree.h:1261

#10 0x00007ff7e696d33c in std::_Rb_tree<DCS::EVENT::Timing*, DCS::EVENT::Timing*, std::_Identity<DCS::EVENT::Timing*>, std::less<DCS::EVENT::Timing*>, std::allocator<DCS::EVENT::Timing*> >::_M_erase_aux (this=0x7ff7e6c46fa0, __first=..., __last=...)

    at /usr/include/c++/10/bits/stl_tree.h:2528

#11 0x00007ff7e696c04e in std::_Rb_tree<DCS::EVENT::Timing*, DCS::EVENT::Timing*, std::_Identity<DCS::EVENT::Timing*>, std::less<DCS::EVENT::Timing*>, std::allocator<DCS::EVENT::Timing*> >::erase (this=0x7ff7e6c46fa0, __x=@0x7ff7853e1458: 0x7ff784f8e8c0)

    at /usr/include/c++/10/bits/stl_tree.h:2542

#12 0x00007ff7e696b871 in std::set<DCS::EVENT::Timing*, std::less<DCS::EVENT::Timing*>, std::allocator<DCS::EVENT::Timing*> >::erase (this=0x7ff7e6c46fa0, __x=@0x7ff7853e1458: 0x7ff784f8e8c0) at /usr/include/c++/10/bits/stl_set.h:685

#13 0x00007ff7e6970a78 in DCS::EVENT::SimulateEvents (phase_end_cycle=1000) at /work/mewais/DCArch/DCSim/Sources/DCS/Event/Simulation.cpp:182

#14 0x00007ff7e6972540 in DCS::CORE::Scheduler::SimulatePhase (this=0x7ff77b29fb50) at /work/mewais/DCArch/DCSim/Sources/DCS/Cores/Scheduler.cpp:102

#15 0x00007ff7e6977fb5 in DCS::CORE::Simple::BasicBlock (this=0x7ff77b29fe00, thread=913617, address=140703824748397, bb=0x7ff78584ada0) at /work/mewais/DCArch/DCSim/Sources/DCS/Cores/Simple.cpp:68

#16 0x00007ff7e68c2039 in SNE::BBREPLACEMENTS::CallBBSim (core=0x7ff77b29fe00, tid=913617, address=140703824748397, bb=0x7ff78584ada0) at /work/mewais/DCArch/DCSim/Sources/SNE/BBReplacements.cpp:1347

I have faced a similar issue before. As far as I can tell, this happens on a corruption of the allocator by freeing things the wrong way (e.g., freeing with a different function than the one used for allocation, freeing a wrong pointer, etc). However, unlike last time, I don't have a guess as to where the cause might be. I tried using -debug -loglevel 4 but nothing in the logs seems relevant to allocation/freeing except line like:

try app_mem_alloc

app_mem_alloc -- DONE

which show no useful information.  Is there a way to log or trace all CLIENT memory allocation/freeing?

Thanks a lot.

[Derek Bruening]

I think you want these level 6 LOG_HEAP prints: https://github.com/DynamoRIO/dynamorio/blob/master/core/heap.c#L4457

To filter by heap category `which` may require source changes but probably worth tweaking the sources.  The ACCOUNT_FOR_ALLOC and _FREE macros are a central point to add logs by `which`.

--
You received this message because you are subscribed to the Google Groups "DynamoRIO Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to dynamorio-use...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/dynamorio-users/9d50b069-b82b-42af-8267-d04abdeae280n%40googlegroups.com.

[Mohammad Ewais]

Thanks a lot. Will give it a try.