Re: [DynInst_API:] Question on potential memory leaks

[Thomas Dullien <thomasdullien@xxxxxxxxxx>]

Hey there,

that is an excellent question :-). As far as I know, yes, but I don't *know* - and the fact that the same code

compiled using a different GCC version does not show the leaks gives further pause.

I will investigate further -- at the moment, the quantities reported are very non-threatening, (850k bytesÂ

over a few dozen full disassemblies), so it is not an urgent question anyhow :-)

Cheers,

Thomas

On Wed, Sep 27, 2017 at 4:44 PM, Xiaozhu Meng <mxz297@xxxxxxxxx> wrote:

Hi Thomas,

I had some memory issues related to ROSE in Dyninst, but they were not about memory leaks. My experiences are that ROSE internally has their own memory management system, including their customized small object allocation, deallocation, and their own implementation for shared pointers. ROSE typically free objects created by ROSE at the very end of the program, specifically, after returning from main and in global destruction time.ÂÂ

I have little experience with LeakSanitizer, but my question is does LeakSanitizer consider code after returning from Main?

Thanks,

--Xiaozhu

On Wed, Sep 27, 2017 at 9:03 AM, Thomas Dullien <thomasdullien@xxxxxxxxxx> wrote:

Hey all,

in the following two example leaks (there are lots in my output, but they are all of one of these two types):

Indirect leak of 8 byte(s) in 1 object(s) allocated from:

  #0 0x7fb7aa213bf0 in operator new(unsigned long) (/usr/lib/x86_64-linux-gnu/libasan.so.3+0xc2bf0)

  #1 0x7fb7a9cc1329 in Dyninst::DataflowAPI::ExpressionConversionVisitor::visit(Dyninst::InstructionAPI::Dereference*) /home/thomasdullien/dyninst-9.3.2/dataflowAPI/src/_expression_ConversionVisitor.C:217

  #2 0x7fb7a9cd6a6a in Dyninst::DataflowAPI::RoseInsnFactory::convertOperand(boost::shared_ptr<Dyninst::InstructionAPI::_expression_>, long, unsigned long) /home/thomasdullien/dyninst-9.3.2/dataflowAPI/src/RoseInsnFactory.C:105

  #3 0x608000104e1f Â(<unknown module>)

Indirect leak of 9 byte(s) in 1 object(s) allocated from:

  #0 0x7fb7aa213bf0 in operator new(unsigned long) (/usr/lib/x86_64-linux-gnu/libasan.so.3+0xc2bf0)

  #1 0x7fb7a9cd3307 in __gnu_cxx::new_allocator<unsigned char>::allocate(unsigned long, void const*) /usr/include/c++/6/ext/new_allocator.h:104

  #2 0x7fb7a9cd3307 in std::allocator_traits<std::allocator<unsigned char> >::allocate(std::allocator<unsigned char>&, unsigned long) /usr/include/c++/6/bits/alloc_traits.h:436

  #3 0x7fb7a9cd3307 in std::_Vector_base<unsigned char, std::allocator<unsigned char> >::_M_allocate(unsigned long) /usr/include/c++/6/bits/stl_vector.h:170

  #4 0x7fb7a9cd3307 in unsigned char* std::vector<unsigned char, std::allocator<unsigned char> >::_M_allocate_and_copy<__gnu_cxx::__normal_iterator<unsigned char const*, std::vector<unsigned char, std::allocator<unsigned char> > > >(unsigned l

ong, __gnu_cxx::__normal_iterator<unsigned char const*, std::vector<unsigned char, std::allocator<unsigned char> > >, __gnu_cxx::__normal_iterator<unsigned char const*, std::vector<unsigned char, std::allocator<unsigned char> > >) /usr/include/c

++/6/bits/stl_vector.h:1222

  #5 0x7fb7a9cd3307 in std::vector<unsigned char, std::allocator<unsigned char> >::operator=(std::vector<unsigned char, std::allocator<unsigned char> > const&) /usr/include/c++/6/bits/vector.tcc:195

  #6 0x7fb7a9cd3307 in SgAsmInstruction::set_raw_bytes(std::vector<unsigned char, std::allocator<unsigned char> >) /home/thomasdullien/dyninst-9.3.2/dataflowAPI/src/RoseImpl.C:1363

  #7 0x6020000d4478 Â(<unknown module>)

Do these seem like real leaks? (This is not from trunk, but the 9.3 release).

Cheers,

Thomas

On Wed, Sep 27, 2017 at 3:59 PM, Thomas Dullien <thomasdullien@xxxxxxxxxx> wrote:

Hey there,

while tracing down some undesired behavior in Functionsimsearch, I compiled and

ran everything under gcc6 and -fsanitize=address, which includes LeakSanitizer.

I get a fairly large-ish number of reported leaks from Rose:

_______________________________________________
Dyninst-api mailing list
Dyninst-api@xxxxxxxxxxx
https://lists.cs.wisc.edu/mailman/listinfo/dyninst-api