1. Stanislav Sedov
  2. valgrind-freebsd
  3. Issues
Issue #7 resolved

Add replacements for libsupc++

Mikolaj Golub
created an issue

libsupc++ is is a c++ library that contains language support functions. In FreeBSD 9.1 and 10 libstdc++ is a filter library, and libsupc++ or libcxxrt are the filtee. So in c++ program new/delete operators may be called from libsupc++, which may confuse valgrind.

E.g. if one run this program under valgrind:

  int main()
      char* buf = new char[10];
      delete [] buf;

      return 0;

it will produce the warning:

==38718== Mismatched free() / delete / delete []
==38718==    at 0x100416E: free (vg_replace_malloc.c:473)
==38718==    by 0x4007BE: main (test.cpp:5)
==38718==  Address 0x2400040 is 0 bytes inside a block of size 10 alloc'd
==38718==    at 0x10047D7: operator new[](unsigned long) (vg_replace_malloc.c:382)
==38718==    by 0x40079D: main (test.cpp:4)

As one can check running valgrind with "--trace-redir=yes -v", this is because valgrind finds redirection for new[] operator in libstdc++ library, but can't find redirection for delete[] operator, which is called directly from libsup++, and uses redirection for free function:

--6729-- REDIR: 0x12dea90 (operator new[](unsigned long)) redirected to 0x1004770
+(operator new[](unsigned long))
--6729-- REDIR: 0x19dd9a0 (free) redirected to 0x1004100 (free)

Another potential issue is if one does not need libstdc++ and wants to explicitly link in -lsupc++. In this case the valgrind will not be able to report about mismatched free() / delete / delete [], as it will not find these operators and will use redirs for malloc/free:

kopusha:~/freebsd/valgrind% cat test.cpp                 
#include <stdlib.h>

int main()
    int* p = new int();


    return 0;
kopusha:~/freebsd/valgrind% gcc -o test test.cpp -lsupc++
kopusha:~/freebsd/valgrind% valgrind --tool=memcheck ./test
==96092== Memcheck, a memory error detector
==96092== Copyright (C) 2002-2012, and GNU GPL'd, by Julian Seward et al.
==96092== Using Valgrind-3.8.0 and LibVEX; rerun with -h for copyright info
==96092== Command: ./test
==96092== HEAP SUMMARY:
==96092==     in use at exit: 0 bytes in 0 blocks
==96092==   total heap usage: 1 allocs, 1 frees, 4 bytes allocated
==96092== All heap blocks were freed -- no leaks are possible
==96092== For counts of detected and suppressed errors, rerun with: -v
==96092== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)

So I think we need to add replacements for libsupc++, something like in the attached patch.

Comments (4)

  1. Log in to comment