I am trying to use GLFW and vulkan in arch linux.
I noticed that I get a memory leak when calling glfwGetRequiredInstanceExtensions. To detect said memory leak, I simply call valgrind with my program.
Valgrind reports:
==13943== LEAK SUMMARY:
==13943== definitely lost: 48 bytes in 2 blocks
==13943== indirectly lost: 48 bytes in 2 blocks
==13943== possibly lost: 0 bytes in 0 blocks
My code is:
int main() {
glfwInit();
uint32_t glfwExtensionCount = 0;
const char** glfwExtensions;
glfwExtensions = glfwGetRequiredInstanceExtensions(&glfwExtensionCount);
glfwTerminate();
return 0;
}
If I comment out glfwGetRequiredExtensions valgrind reports no leaks.
In addition, I don;t want to try to free that memory myself because the documentation for that function says:
Pointer lifetime:
The returned array is allocated and freed by GLFW. You should not free it yourself. It is guaranteed to be valid only until the library is terminated.
I know it's just 48 bytes, but I'd prefer to have no memory leaks, iif only for OCD sake.
Is there a way to appropriately avoid that issue?
Related
Is this code still going to leak if instead of declaring the pointers as part of main I declare them globally?
I tested with Valgrind memcheck and it doesn't
class Test1 {
public:
Test1() { std::cout << "Constructor of Test " << std::endl; }
~Test1() { std::cout << "Destructor of Test " << std::endl; }
};
//Memory leaked or not when globally declared?
// Test1 *t1;
// Test1 *t2;
// Test1 *t;
int main()
{
//mem will leak if not deallocated later
Test1 *t1;
Test1 *t2;
Test1 *t;
try {
t1=new Test1[100];
t2=new Test1;
t =new Test1;
throw 10;
}
catch(int i)
{
std::cout << "Caught " << i << std::endl;
// delete []t1;
// delete t;
// delete t2;
}
return 0;
}
Declaring the variable global will make the pointer variable global, not what the pointer points to (which is already global as it is located on the heap).
Therefore, your current implementation also has a leak.
Local variables get destroyed when out of scope, but what they point to is not automatically out. Suggestion: forget completety new and delete operators and use STL or smart pointers.
Edit: You are asking why valgrind does not detect it, this is a different question than the original (I edited to add a tag).
Right now you're always leaking memory, regardless if you're declaring pointers in main or globally.
Whenever you use new in your code, you need to use a delete or delete[].
In modern C++, using new is considered a bad practice, you should be using std::vector, if you want an array, or std::unique_ptr if you're managing a pointer to an object.
As was mentioned already in other answers, the allocated object's destructor will not be called in both variants of your program, the scope and lifetime of the pointers do not influence what happens to the pointees, but you showed that already by printing in the destructor.
Valgrind will report this slightly differently however.
I ran the with a shorter array of 2 elements to reduce the amount of output.
The heap summary, which tells you what data remains on the heap at the end of the run, is the same for both programs:
==397== HEAP SUMMARY:
==397== in use at exit: 12 bytes in 3 blocks
==397== total heap usage: 6 allocs, 3 frees, 76,944 bytes allocated
That means both programs never deallocated the objects.
Valgrind does however make a difference between "definitely lost" allocations, with no reference to the memory blocks remaining in any variable and "still reachable" allocations, where a reference remains.
The leak summary with local pointers
==397== LEAK SUMMARY:
==397== definitely lost: 12 bytes in 3 blocks
==397== indirectly lost: 0 bytes in 0 blocks
==397== possibly lost: 0 bytes in 0 blocks
==397== still reachable: 0 bytes in 0 blocks
==397== suppressed: 0 bytes in 0 blocks
The leak summary with global pointers
==385== LEAK SUMMARY:
==385== definitely lost: 0 bytes in 0 blocks
==385== indirectly lost: 0 bytes in 0 blocks
==385== possibly lost: 0 bytes in 0 blocks
==385== still reachable: 12 bytes in 3 blocks
==385== of which reachable via heuristic:
==385== length64 : 10 bytes in 1 blocks
If the pointers are local, valgrind can be sure that no reference remains, because after main returns, the stack locations are no longer valid.
If the pointers are global, they remain valid and could thus still be used or deallocated.
Why does valgrind make this distinction?
Especially in historic C programs it may be considered legitimate to allocate some memory once and use it throughout the execution, without bothering to later free the memory. The operating system will clean up the whole virtual memory space of the program anyway once the program exits. So while this could be a bug, it could also be intentional.
If you are interested in such leaks, valgrind itself tells you how it must be called to see them:
==405== Reachable blocks (those to which a pointer was found) are not shown.
==405== To see them, rerun with: --leak-check=full --show-leak-kinds=all
"Definitely lost" memory is always suspicious, however, and that is why valgrind distinguished the cases. The value of a tool like valgrind lies in its precision. It is not sufficient to report many actual errors, in order to be useful it must also strive to produce a low number of false positives, otherwise looking at the reports would too often be a waste of developer time.
In modern C++, there are not many excuses for leaking memory, as std::unique_ptr should be the way to allocate dynamic objects. std::vector should be used for dynamic arrays and local objects used wherever possible as the compiler never forgets a deallocation. Even for singletons, the noise in the output of tools like valgrind and address sanitizer usually outweighs the usually minuscule benefits of saving one destructor call or deallocation.
I am creating a c++ object with two slightly different ways, in the following code when CASE is 0 there is a memory leak, but no memory leak in the else case.
#include <string>
#define CASE 1
class A {
private:
std::string *s;
public:
A(std::string *p_s) { s = p_s; }
};
int main() {
#if CASE==0
auto a = A(new std::string("Hello"));
#else
auto s = std::string("Hello");
auto a = A(&s);
#endif
}
when I set CASE 0 the valgrind says that there is a memory leak
valgrind ./a.out
==24351== Memcheck, a memory error detector
==24351== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al.
==24351== Using Valgrind-3.13.0 and LibVEX; rerun with -h for copyright info
==24351== Command: ./a.out
==24351==
==24351==
==24351== HEAP SUMMARY:
==24351== in use at exit: 32 bytes in 1 blocks
==24351== total heap usage: 2 allocs, 1 frees, 72,736 bytes allocated
==24351==
==24351== LEAK SUMMARY:
==24351== definitely lost: 32 bytes in 1 blocks
==24351== indirectly lost: 0 bytes in 0 blocks
==24351== possibly lost: 0 bytes in 0 blocks
==24351== still reachable: 0 bytes in 0 blocks
==24351== suppressed: 0 bytes in 0 blocks
==24351== Rerun with --leak-check=full to see details of leaked memory
==24351==
==24351== For counts of detected and suppressed errors, rerun with: -v
==24351== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)
in the else case (i.e. define CASE 1) it works as expected and valgrind doesn't report any memory leak.
I am not able to understand in either case I am passing a pointer and I am not explicitly freeing the memory then why do they behave differently?
The reason for this behavior is that your class A is not designed to take ownership of std::string* passed into it: its std::string *s member assumes that the object the pointer to which is passed into the constructor would be destroyed externally.
This leads to a memory leak when the object is not destroyed: delete is never called on new string passed into the constructor in the first case, causing a memory leak.
In the second case the pointer points to a string in automatic storage. It gets destroyed when main ends, preventing the memory leak.
You don't get a memory leak because you have a pointer.
You get a memory leak because you new'd something and did not delete it.
Obtaining a pointer to an automatic storage variable does not stop the variable from being cleaned up automatically.
In fact, attempting to delete &a in that case would be wrong/broken/evil/illegal/heresy.
CASE==0
auto a = A(new std::string("Hello"));
This means you are new-ing an object in heap -> you have to explicitly delete it - that you didn't in the snippet -> memory leaks.
else
auto s = std::string("Hello");
auto a = A(&s);
auto s = std::string("Hello");: This means you are creating an object in stack and,
auto a = A(&s);: take its address (in stack, of course).
The created object will be auto-deleted once the variable goes out of scope
-> no memory leak.
This is no different from:
// first case, leak
int *j = new int (5);
//
// second case, no leak
int q = 5;
int *j = &q;
In the first case, we've allocated memory with new and it's our responsibility to delete it when we're done. In the second case, we create q on the stack and it's destroyed when it goes out of scope.
I want to allocate memory for a struct that contains std::vector. After allocating it, I will push_back some data to it.
After all, I need to destroy my allocated struct. I want to know how can it be done with no memory corruption.
Here is my code:
typedef struct my_struct_t{
int a, b;
vector<unsigned> vec;
}
} MYSTRUCT;
int main(int argc, const char * argv[])
{
MYSTRUCT* ptr_s = new MYSTRUCT;
for(int i = 0 ; i < 100 ; i++){
ptr_s->vec.push_back(i);
}
ptr_s->vec.clear();
delete ptr_s;
return 0;
}
I tried to use clear as it is supposed to call destructor. But after valgrind-ing my code, there are still some blocks reachable. I also tried to deallocate vector using this:
vector<unsigned>().swap(ptr_s.vec)
But with no success.
output of `valgrind':
==52635== HEAP SUMMARY:
==52635== in use at exit: 10,360 bytes in 5 blocks
==52635== total heap usage: 147 allocs, 142 frees, 25,198 bytes allocated
==52635==
==52635== LEAK SUMMARY:
==52635== definitely lost: 0 bytes in 0 blocks
==52635== indirectly lost: 0 bytes in 0 blocks
==52635== possibly lost: 0 bytes in 0 blocks
==52635== still reachable: 10,360 bytes in 5 blocks
==52635== suppressed: 0 bytes in 0 blocks
==52635== Reachable blocks (those to which a pointer was found) are not shown.
==52635== To see them, rerun with: --leak-check=full --show-leak-kinds=all
Thank you everyone in advance.
update:
I noticed that the source of memory corruption in my application is in somewhere else. So I added an update. Here is the new code:
MYSTRUCT* ptr_s1 = new MYSTRUCT;
MYSTRUCT* ptr_s2 = new MYSTRUCT;
for(int i = 0 ; i < 100 ; i++){
ptr_s1->vec.push_back(i);
}
memcpy(ptr_s2 , ptr_s1, sizeof(*ptr_s1));
delete ptr_s1;
delete ptr_s2; // here I get seg fault
return 0;
As soon as deleting ptr_s2, seg fault happens.
Update: proper way, based on the accepted answer:
typedef struct my_struct_t{
int a, b;
vector<unsigned> vec;
inline my_struct_t operator=(const my_struct_t &s ){
a = s.a;
b = s.b;
vec = s.vec;
return s;
}
} MYSTRUCT;
MYSTRUCT* ptr_s1 = new MYSTRUCT;
MYSTRUCT* ptr_s2 = new MYSTRUCT;
for(int i = 0 ; i < 100 ; i++){
ptr_s1->vec.push_back(i);
}
// no memcpy
// memcpy(ptr_s2 , ptr_s1, sizeof(*ptr_s1));
*ptr_s2 = *ptr_s1;
delete ptr_s1;
delete ptr_s2; // no more sget seg fault
return 0;
You don't need to call std::vector::clear or do something else, the destructor will get called when you delete it via delete ptr_s;.
The still reachable matter is explained in Valgrind FAQ.
My program uses the C++ STL and string classes. Valgrind reports
'still reachable' memory leaks involving these classes at the exit of
the program, but there should be none.
First of all: relax, it's probably not a bug, but a feature. Many
implementations of the C++ standard libraries use their own memory
pool allocators. Memory for quite a number of destructed objects is
not immediately freed and given back to the OS, but kept in the
pool(s) for later re-use. The fact that the pools are not freed at the
exit of the program cause Valgrind to report this memory as still
reachable. The behaviour not to free pools at the exit could be called
a bug of the library though.
Update:
Briefly, don't copy classes with memcpy, if you use memcpy to copy a class object whose destructor deletes a pointer within itself (std::vector member in your case), you will end up with double delete when the second instance of the object is destroyed.
The right way is copy/move constructor and/or assignment operator for classes.
I have a inline function defined as following:
inline string Change(char *pointer) {
string str;
char temp[32] = "";
sprintf(temp,"%c:%c:%c:%c:%c:%c", //line 1
temp[0],temp[1],temp[2],
temp[3],temp[4],temp[5],
);
str = temp;
return str;
}
when I use memory leak tool to check it, it indicates line 1(marked above) is memory leak.
What is the problem of the above code?
I created fully compilable example:
#include <string>
#include <iostream>
#include <cstdio>
std::string Change( char * ) {
std::string str;
char temp[32] = "";
sprintf(temp,"%c:%c:%c:%c:%c:%c", //line 1
temp[0],temp[1],temp[2],
temp[3],temp[4],temp[5]
);
str = temp;
return str;
}
int main()
{
char a[]={"abaaaaa2"};
std::cout<<Change(a)<<std::endl;
}
When running under valgrind, I get no leaks detected:
==16829==
==16829== HEAP SUMMARY:
==16829== in use at exit: 0 bytes in 0 blocks
==16829== total heap usage: 0 allocs, 0 frees, 0 bytes allocated
==16829==
==16829== All heap blocks were freed -- no leaks are possible
==16829==
==16829== For counts of detected and suppressed errors, rerun with: -v
==16829== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 15 from 8)
If you want to know exactly where is the leak you can use plugins. you can pick out a plugin that will be convenient for you. For me, it is deleaker. There are so many developments in this field!!
If you want to know exactly where is the leak you can use plugins. you can pick out a plugin >that will be convenient for you. For me, it is deleaker. There are so many developments in >this field!!
Thank. It helped me.
The code above alone is leak-free. The tool might indicate a leak in either of the two cases:
the string returned from teh function is assigned to another string variable somewhere and that other variable is not destroyed before the tool is run - then technically the string body is still allocated at that point and the tool reports it
the string body allocator cached the string body block for future reuse and the tool is run before the allocator releases all cached blocks - then again technically the string body is allocated and the tool reports it.
The tool is malfunctioning; there's no memory leak there.
Memory leak only occurs when you acquire free store memory using new or new [] and do not release it back by calling delete or delete[] respectively.
std::string does internally allocate on freestore but you are returning it as return type, And that is not leaking memory.
The code you showed does not use new or new [] so there is no memory leak in the code you show.
The tool you use seems to be misleading. or ou need to show us your real code to get an better answer.
Consider the following C++ program:
#include <cstdlib> // for exit(3)
#include <string>
#include <iostream>
using namespace std;
void die()
{
exit(0);
}
int main()
{
string s("Hello, World!");
cout << s << endl;
die();
}
Running this through valgrind shows this (some output trimmed for brevity):
==1643== HEAP SUMMARY:
==1643== in use at exit: 26 bytes in 1 blocks
==1643== total heap usage: 1 allocs, 0 frees, 26 bytes allocated
==1643==
==1643== LEAK SUMMARY:
==1643== definitely lost: 0 bytes in 0 blocks
==1643== indirectly lost: 0 bytes in 0 blocks
==1643== possibly lost: 26 bytes in 1 blocks
==1643== still reachable: 0 bytes in 0 blocks
==1643== suppressed: 0 bytes in 0 blocks
As you can see, there's a possibility that 26 bytes allocated on the heap were lost. I know that the std::string class has a 12-byte struct (at least on my 32-bit x86 arch and GNU compiler 4.2.4), and "Hello, World!" with a null terminator has 14 bytes. If I understand it correctly, the 12-byte structure contains a pointer to the character string, the allocated size, and the reference count (someone correct me if I'm wrong here).
Now my questions: How are C++ strings stored with regard to the stack/heap? Does a stack object exist for a std::string (or other STL containers) when declared?
P.S. I've read somewhere that valgrind may report a false positive of a memory leak in some C++ programs that use STL containers (and "almost-containers" such as std::string). I'm not too worried about this leak, but it does pique my curiosity regarding STL containers and memory management.
Calling exit "terminates the program without leaving the current block and hence without
destroying any objects with automatic storage duration".
In other words, leak or not, you shouldn't really care. When you call exit, you're saying "close this program, I no longer care about anything in it." So stop caring. :)
Obviously it's going to leak resources because you never let the destructor of the string run, absolutely regardless of how it manages those resources.
Others are correct, you are leaking because you are calling exit. To be clear, the leak isn't the string allocated on the stack, it is memory allocated on the heap by the string. For example:
struct Foo { };
int main()
{
Foo f;
die();
}
will not cause valgrind to report a leak.
The leak is probable (instead of definite) because you have an interior pointer to memory allocated on the heap. basic_string is responsible for this. From the header on my machine:
* A string looks like this:
*
* #code
* [_Rep]
* _M_length
* [basic_string<char_type>] _M_capacity
* _M_dataplus _M_refcount
* _M_p ----------------> unnamed array of char_type
* #endcode
*
* Where the _M_p points to the first character in the string, and
* you cast it to a pointer-to-_Rep and subtract 1 to get a
* pointer to the header.
They key is that _M_p doesn't point to the start of the memory allocated on the heap, it points to the first character in the string. Here is a simple example:
struct Foo
{
Foo()
{
// Allocate 4 ints.
m_data = new int[4];
// Move the pointer.
++m_data;
// Null the pointer
//m_data = 0;
}
~Foo()
{
// Put the pointer back, then delete it.
--m_data;
delete [] m_data;
}
int* m_data;
};
int main()
{
Foo f;
die();
}
This will report a probable leak in valgrind. If you comment out the lines where I move m_data valgrind will report 'still reachable'. If you uncomment the line where I set m_data to 0 you'll get a definite leak.
The valgrind documentation has more information on probable leaks and interior pointers.
Of course this "leaks", by exiting before s's stack frame is left you don't give s's destructor a chance to execute.
As for your question wrt std::string storage: Different implementations do different things. Some allocate some 12 bytes on the stack which is used if the string is 12 bytes or shorter. Longer strings go to the heap. Other implementations always go to the heap. Some are reference counted and with copy-on-write semantics, some not. Please turn to Scott Meyers' Effective STL, Item 15.
gcc STL has private memory pool for containers and strings. You can turn this off ; look in valgrind FAQ
http://valgrind.org/docs/manual/faq.html#faq.reports
I would avoid using exit() I see no real reason to use that call. Not sure if it will cause the process to stop instantly without cleaning up the memory first although valgrind does still appear to run.