Does anybody have any idea why address sanitizer is not flagging this very obvious memory leak
class A {
public:
A() = default;
};
TEST_F(LibrdfSerializerTests, Test) {
A* a = new A;
}
built with the following added to cmake:
set(CMAKE_CXX_FLAGS_DEBUG "${CMAKE_CXX_FLAGS_DEBUG} -fno-omit-frame-pointer -fsanitize=address")
set(CMAKE_LINKER_FLAGS_DEBUG "${CMAKE_LINKER_FLAGS_DEBUG} -fno-omit-frame-pointer -fsanitize=address")
You can try using the ASAN_OPTIONS=detect_leaks=1 while executing the binary to detect leaks. Using the example from the documentation
❯ cat leak.c
#include <stdlib.h>
void *p;
int main() {
p = malloc(7);
p = 0; // The memory is leaked here.
return 0;
}
Compile the program
clang -fsanitize=address -g leak.c
and then execute it as follows:
ASAN_OPTIONS=detect_leaks=1 ./a.out
Output:
=================================================================
==63987==ERROR: LeakSanitizer: detected memory leaks
Direct leak of 7 byte(s) in 1 object(s) allocated from:
#0 0x1034c109d in wrap_malloc+0x9d (libclang_rt.asan_osx_dynamic.dylib:x86_64h+0x4609d)
#1 0x103477ef8 in main leak.c:4
#2 0x7fff6b30fcc8 in start+0x0 (libdyld.dylib:x86_64+0x1acc8)
SUMMARY: AddressSanitizer: 7 byte(s) leaked in 1 allocation(s).
Same for CPP
❯ cat memory-leak.cpp
#include <cstdlib>
#include <cstdio>
class A {
public:
A() = default;
};
int main() {
char const* asanOpt = std::getenv("ASAN_OPTIONS");
std::printf("%s\n", asanOpt);
A* a = new A;
return 0;
}
Compile it
clang++ -g memory-leak.cpp -fsanitize=address
While executing the binary, use the option to enable leak detections
ASAN_OPTIONS=detect_leaks=1 ./a.out
Output:
detect_leaks=1
=================================================================
==69309==ERROR: LeakSanitizer: detected memory leaks
Direct leak of 1 byte(s) in 1 object(s) allocated from:
#0 0x109ea556d in wrap__Znwm+0x7d (libclang_rt.asan_osx_dynamic.dylib:x86_64h+0x5256d)
#1 0x109e4bf48 in main memory-leak.cpp:7
#2 0x7fff6b30fcc8 in start+0x0 (libdyld.dylib:x86_64+0x1acc8)
SUMMARY: AddressSanitizer: 1 byte(s) leaked in 1 allocation(s).
Tested on:
MacOS 10.15
With clang
clang version 10.0.1
Target: x86_64-apple-darwin19.6.0
Thread model: posix
Related
Hello stackoverflow community, I am creating a memory leak to use ASAN and detect memory leaks.
$ export MallocNanoZone='0' # to avoid https://stackoverflow.com/q/64126942/9497703 on OS X
$ cat new_delete.cc
class Dummy {
public:
Dummy(int x) {
sz = x;
}
private:
int sz;
};
void func(int i) {
Dummy* p = new Dummy(i);
if (i < 50) {
// If return from here then there is a memory leak on the
// heap. Dummy is not freed.
return;
}
// Do useful things.
delete p;
}
int main() {
func(10);
}
$ clang++ -fsanitize=address -g -O0 new_delete.cc
$ ./a.out
I was expecting ASAN to detect this memory leak. However, it didn't.
Can anyone point out what I am missing here? I am using OS X and following clang version:
$ clang++ --version
Apple clang version 12.0.0 (clang-1200.0.32.28)
Target: x86_64-apple-darwin21.6.0
Thread model: posix
InstalledDir: /Library/Developer/CommandLineTools/usr/bin
This is a known issue - algorithm used in Lsan is probabilistic and does not guarantee that all leaks are detected (see #937 for details). E.g. in your case if we change main to
int main() {
int a[100];
func(10);
}
clang starts to detect the leak:
$ clang++ -fsanitize=address new_delete.cc && ./a.out
=================================================================
==349258==ERROR: LeakSanitizer: detected memory leaks
Direct leak of 4 byte(s) in 1 object(s) allocated from:
I am learning about copy constructor and shallow and deep copy. I was following this video: Copying and Copy Constructors in C++
The following code is copied directly from the video and demonstrates shallow copying... (at 9:30 in the video)
This code is supposed to crash after running because the deconstructor will try to deallocate the same memory twice (first for string and later for string2). The first deletion should work fine but the second one should cause the program to crash as we are trying to delete unallocated memory.
Surprisingly, this doesn't happen in my case. I complied code in my command prompt using g++ copying_and_copy_constructor.cpp and it compiled fine and ran it using a.exe. No errors.
#include<iostream>
#include<cstring>
#include<string>
using std::endl;
using std::cout;
class String
{
private:
char* m_Buffer;
unsigned int m_size;
public:
String(const char* string)
{
m_size = strlen(string);
m_Buffer = new char[m_size+1];
memcpy(m_Buffer,string,m_size);
m_Buffer[m_size] = 0;
}
~String()
{
delete [] m_Buffer;
}
friend std::ostream& operator << (std::ostream& stream, const String& string);
};
std::ostream& operator<<(std::ostream& stream, const String& string)
{
stream<< string.m_Buffer;
return stream;
}
int main()
{
String string = "My string";
String string2 = string;
cout<<string2<<endl;
cout<<string;
return 0;
}
I even tried checking in the debugger. I compiled the code using g++ -g copying_and_copy_constructor.cpp and then gdb a.exe. Here is the output of that:
GNU gdb (GDB) 7.6.1
Copyright (C) 2013 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type "show copying"
and "show warranty" for details.
This GDB was configured as "mingw32".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>...
Reading symbols from D:\a.exe...done.
(gdb) start
Temporary breakpoint 1 at 0x401446: file copying_and_copy_constructor.cpp, line 43.
Starting program: D:\a.exe
[New Thread 44892.0x8258]
[New Thread 44892.0x6df8]
[New Thread 44892.0xadd8]
[New Thread 44892.0x9658]
Temporary breakpoint 1, main () at copying_and_copy_constructor.cpp:43
43 String string = "My string";
(gdb) c
Continuing.
My string
My string[Inferior 1 (process 44892) exited normally]
(gdb)
The program is not being run.
(gdb) q
This line confuses me My string[Inferior 1 (process 44892) exited normally]. How is this code is exiting normally?
The person in the video is using VS-Code... How can I get the same error in the command prompt?
Crash as shown in the video:
(I don't have vs code as of now (might install it later))
For me (Fedora 32 x86_64) it does crash:
$ g++ -o q q.C -Wall -g;./q
My string
free(): double free detected in tcache 2
Aborted
But I definitely agree such code may look running fine. This is why there is ASAN:
$ g++ -o q q.C -Wall -g -fsanitize=address;./q
My string
=================================================================
==3388436==ERROR: AddressSanitizer: attempting double-free on 0x602000000010 in thread T0:
#0 0x7fb76f262cd7 in operator delete[](void*) (/lib64/libasan.so.6+0xb2cd7)
#1 0x4016e9 in String::~String() /home/jkratoch/t/q.C:25
#2 0x40144b in main /home/jkratoch/t/q.C:42
#3 0x7fb76ecbc041 in __libc_start_main ../csu/libc-start.c:308
#4 0x40120d in _start (/quad/home/jkratoch/t/q+0x40120d)
0x602000000010 is located 0 bytes inside of 10-byte region [0x602000000010,0x60200000001a)
freed by thread T0 here:
#0 0x7fb76f262cd7 in operator delete[](void*) (/lib64/libasan.so.6+0xb2cd7)
#1 0x4016e9 in String::~String() /home/jkratoch/t/q.C:25
#2 0x40143e in main /home/jkratoch/t/q.C:43
#3 0x7fb76ecbc041 in __libc_start_main ../csu/libc-start.c:308
previously allocated by thread T0 here:
#0 0x7fb76f2621d7 in operator new[](unsigned long) (/lib64/libasan.so.6+0xb21d7)
#1 0x4015d6 in String::String(char const*) /home/jkratoch/t/q.C:18
#2 0x4013a0 in main /home/jkratoch/t/q.C:42
#3 0x7fb76ecbc041 in __libc_start_main ../csu/libc-start.c:308
SUMMARY: AddressSanitizer: double-free (/lib64/libasan.so.6+0xb2cd7) in operator delete[](void*)
==3388436==ABORTING
In the case you do not want or even cannot recompile the program with -fsanitize=address you can use Valgrind (but it is slower and it does not detect everything):
$ g++ -o q q.C -Wall -g;valgrind ./q
==3388447== Memcheck, a memory error detector
==3388447== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al.
==3388447== Using Valgrind-3.16.0 and LibVEX; rerun with -h for copyright info
==3388447== Command: ./q
==3388447==
My string
==3388447== Invalid free() / delete / delete[] / realloc()
==3388447== at 0x483C59C: operator delete[](void*) (vg_replace_malloc.c:649)
==3388447== by 0x40139E: String::~String() (q.C:25)
==3388447== by 0x401277: main (q.C:42)
==3388447== Address 0x4db5c80 is 0 bytes inside a block of size 10 free'd
==3388447== at 0x483C59C: operator delete[](void*) (vg_replace_malloc.c:649)
==3388447== by 0x40139E: String::~String() (q.C:25)
==3388447== by 0x40126B: main (q.C:43)
==3388447== Block was alloc'd at
==3388447== at 0x483B582: operator new[](unsigned long) (vg_replace_malloc.c:431)
==3388447== by 0x401334: String::String(char const*) (q.C:18)
==3388447== by 0x40121B: main (q.C:42)
==3388447==
My string==3388447==
==3388447== HEAP SUMMARY:
==3388447== in use at exit: 0 bytes in 0 blocks
==3388447== total heap usage: 3 allocs, 4 frees, 73,738 bytes allocated
==3388447==
==3388447== All heap blocks were freed -- no leaks are possible
==3388447==
==3388447== For lists of detected and suppressed errors, rerun with: -s
==3388447== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 0 from 0)
I use gcc 4.8.5 on linux. I want to use address sanitizer but it doesn't return any information about the program. Flags:
SET(CMAKE_CXX_FLAGS "-Wall -Wno-error -g -std=c++11 -fno-omit-frame-pointer -fsanitize=address")
SET(CMAKE_LINKER_FLAGS "${CMAKE_LINKER_FLAGS} -fno-omit-frame-pointer -fsanitize=address")
Linked libraries:
target_link_libraries(testcpp asan)
The test program with a memory leak:
int main()
{
int *prt = new int;
return 0;
}
What is wrong ?
With GCC7 on a recent Debian/Sid/x86-64 I compiled this
// file irbis.cc
int main()
{
int *prt = new int;
return 0;
}
using
g++ -fsanitize=address -g3 -std=c++11 irbis.cc -o irbis
and at execution of ./irbis a leak is rightfully detected :
=================================================================
==22742==ERROR: LeakSanitizer: detected memory leaks
Direct leak of 4 byte(s) in 1 object(s) allocated from:
#0 0x7f77ea911340 in operator new(unsigned long)
(/usr/lib/x86_64-linux-gnu/libasan.so.4+0xdb340)
#1 0x55ea91cca81b in main /home/basile/tmp/irbis.cc:4
#2 0x7f77e9c1f2e0 in __libc_start_main
(/lib/x86_64-linux-gnu/libc.so.6+0x202e0)
SUMMARY: AddressSanitizer: 4 byte(s) leaked in 1 allocation(s).
So upgrade your GCC compiler (to at least GCC6). I do know that GCC4.8 had incomplete support for address sanitizer & C++11 (BTW, GCC4.8 is obsolete, and so is GCC5, in november 2017).
The cause of the problem might be that the main doesn't use ptr so it probably was optimized out entierly. Consider this instead:
// file irbis.cc
int main()
{
int *prt = new int;
return *ptr;
}
Even after introducing an intentional memory leak valgrind shows:
==13483== HEAP SUMMARY:
==13483== in use at exit: 0 bytes in 0 blocks
==13483== total heap usage: 0 allocs, 0 frees, 0 bytes allocated
==13483==
==13483== All heap blocks were freed -- no leaks are possible
The executable was compiled with G++ 4.1.2 and 4.6.2 with:
g++ -ftemplate-depth-128 -O0 -fno-inline -Wall -pedantic -g -pthread -Wno-long-long -Wno-uninitialized <snipped definitions and include directives from the build system>
I've tried with Valgrind 3.5.0 and 3.6.1 like:
valgrind --leak-check=full --undef-value-errors=no --show-reachable=yes <executable args>
Within the framework of the library I'm working on, I'm using a simple test case:
#include "pwiz/utility/misc/Std.hpp"
#include "pwiz/utility/misc/Filesystem.hpp"
#include "pwiz/data/identdata/IdentDataFile.hpp"
using namespace pwiz::cv;
using namespace pwiz::data;
using namespace pwiz::identdata;
using namespace pwiz::util;
int main(int argc, char** argv)
{
vector<string> args(argv+1, argv+argc);
BOOST_FOREACH(const bfs::path& filename, args)
{
// intentional memory leak
IdentDataFile* idp = new IdentDataFile(filename.string());
IdentDataFile& id = *idp;
cout << filename.string() << " "
<< id.analysisCollection.spectrumIdentification[0]->activityDate << " "
<< id.analysisCollection.spectrumIdentification[0]->spectrumIdentificationListPtr->spectrumIdentificationResult.size()
<< "\n";
}
return 0;
}
Obviously I don't expect others to be able to compile this, but anyway I suspect it's something about the library that's tripping up valgrind so a simpler test case would be pointless. And I know that the for loop is being executed because I get the cout output during Valgrind execution. How can I debug it without simplifying further?
It boiled down to the linker options actually. I was compiling with -static, so valgrind did not have a chance to substitute its own malloc implementation. Unfortunate that valgrind doesn't at least warn about this though!
The code:
#include <vector>
#include <stack>
using namespace std;
class blub {};
class intvec : public std::vector<int, std::allocator<int> >, public blub {};
int main()
{
std::stack<int, intvec> s;
}
compiles with both g++ (4.4.3) and llvm-g++ (4.2.1), but the output of the latter seg faults:
$ g++ main.cc && ./a.out
$ llvm-g++ main.cc && ./a.out
Segmentation fault
It appears to be an issue of freeing something that wasn't allocated. Is this a bug in llvm-gcc?
Update: Based on the discuss on the llvm mailing list, it looks like this is a bug, either in llvm-gcc or its implementation of the STL that has been fixed in newer versions. I haven't bother to install and build llvm-gcc from their repository to find out, however.
Okay. So I ran this on Ubuntu 10.10 x64 and I see the segmentation fault. Here's some details. In general, my summary seems to be that this is a bug in the compiler. (Note that I'm not the original question asker, I was merely able to reproduce his results).
I've also forwarded this to the llvm mailing list at http://lists.cs.uiuc.edu/pipermail/llvmdev/2010-November/036231.html
wlynch#green:/tmp$ llvm-g++ --version
llvm-g++ (GCC) 4.2.1 (Based on Apple Inc. build 5658) (LLVM build)
Copyright (C) 2007 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
wlynch#green:/tmp$ llvm-g++ -O0 -g main.cc && ./a.out
Segmentation fault
wlynch#green:/tmp$ llvm-g++ -O3 -g main.cc && ./a.out
Segmentation fault
(gdb) bt
#0 0x00007ffff780aa75 in *__GI_raise (sig=<value optimized out>) at ../nptl/sysdeps/unix/sysv/linux/raise.c:64
#1 0x00007ffff780e5c0 in *__GI_abort () at abort.c:92
#2 0x00007ffff78444fb in __libc_message (do_abort=<value optimized out>, fmt=<value optimized out>) at ../sysdeps/unix/sysv/linux/libc_fatal.c:189
#3 0x00007ffff784e5b6 in malloc_printerr (action=3, str=0x7ffff791ead3 "free(): invalid pointer", ptr=<value optimized out>) at malloc.c:6266
#4 0x00007ffff7854e83 in *__GI___libc_free (mem=<value optimized out>) at malloc.c:3738
#5 0x0000000000401476 in __gnu_cxx::new_allocator<int>::deallocate (this=0x7fffffffe5a8, __p=0x62c000, unnamed_arg=4) at include/c++/4.2.1/ext/new_allocator.h:97
#6 0x00000000004014b1 in std::_Vector_base<int, std::allocator<int> >::_M_deallocate (this=0x7fffffffe5a8, __p=0x62c000, __n=4) at include/c++/4.2.1/bits/stl_vector.h:146
#7 0x00000000004014fe in std::_Vector_base<int, std::allocator<int> >::~_Vector_base (this=0x7fffffffe5a8) at include/c++/4.2.1/bits/stl_vector.h:132
#8 0x00000000004017cf in std::vector<int, std::allocator<int> >::~vector (this=0x7fffffffe5a8) at include/c++/4.2.1/bits/stl_vector.h:287
#9 0x0000000000401886 in intvec::~intvec (this=0x7fffffffe5a8) at main.cc:6
#10 0x00000000004018a4 in std::stack<int, intvec>::~stack (this=0x7fffffffe5a8) at include/c++/4.2.1/bits/stl_stack.h:99
#11 0x0000000000400c01 in main () at main.cc:10
We also get a free of an invalid pointer. Which makes sense from the traceback.
wlynch#green:/tmp$ valgrind ./a.out
==4644== Memcheck, a memory error detector
==4644== Copyright (C) 2002-2009, and GNU GPL'd, by Julian Seward et al.
==4644== Using Valgrind-3.6.0.SVN-Debian and LibVEX; rerun with -h for copyright info
==4644== Command: ./a.out
==4644==
==4644== Invalid free() / delete / delete[]
==4644== at 0x4C270BD: free (vg_replace_malloc.c:366)
==4644== by 0x401475: __gnu_cxx::new_allocator<int>::deallocate(int*, unsigned long) (new_allocator.h:97)
==4644== by 0x4014B0: std::_Vector_base<int, std::allocator<int> >::_M_deallocate(int*, unsigned long) (stl_vector.h:146)
==4644== by 0x4014FD: std::_Vector_base<int, std::allocator<int> >::~_Vector_base() (stl_vector.h:132)
==4644== by 0x4017CE: std::vector<int, std::allocator<int> >::~vector() (stl_vector.h:287)
==4644== by 0x401885: intvec::~intvec() (main.cc:6)
==4644== by 0x4018A3: std::stack<int, intvec>::~stack() (stl_stack.h:99)
==4644== by 0x400C00: main (main.cc:10)
==4644== Address 0x5433000 is not stack'd, malloc'd or (recently) free'd
==4644==
==4644==
==4644== HEAP SUMMARY:
==4644== in use at exit: 1 bytes in 1 blocks
==4644== total heap usage: 1 allocs, 1 frees, 1 bytes allocated
==4644==
==4644== LEAK SUMMARY:
==4644== definitely lost: 1 bytes in 1 blocks
==4644== indirectly lost: 0 bytes in 0 blocks
==4644== possibly lost: 0 bytes in 0 blocks
==4644== still reachable: 0 bytes in 0 blocks
==4644== suppressed: 0 bytes in 0 blocks
==4644== Rerun with --leak-check=full to see details of leaked memory
==4644==
==4644== For counts of detected and suppressed errors, rerun with: -v
==4644== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 4 from 4)
I reduced the test case a bit. I'm actually leaning towards this being a STL implementation error, rather than a compiler error.
#include <vector>
class blub {};
class intvec : public std::vector<int>, public blub {};
int main() {
intvec d;
intvec e(d);
}
To figure out what's actually happening, try to compile with the -g flag to enable debug information to be emitted, then run valgrind ./a.out to get a stack trace where the segfault occurs.
does not segfault for me, what platform are you using?
macmini:stackoverflow samm$ llvm-g++ --version
llvm-g++ (GCC) 4.2.1 (Based on Apple Inc. build 5658) (LLVM build)
Copyright (C) 2007 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
macmini:stackoverflow samm$ cat stack.cc
#include <vector>
#include <stack>
using namespace std;
class blub {};
class intvec : public std::vector<int, std::allocator<int> >, public blub {};
int main()
{
std::stack<int, intvec> s;
}
macmini:stackoverflow samm$ llvm-g++ -g stack.cc
macmini:stackoverflow samm$ ./a.out
macmini:stackoverflow samm$ echo $?
0
macmini:stackoverflow samm$