Gtkmm / c ++ first hello world memory leak example

Question

I am trying to learn gtkmm and decided to try gtkmm 2.4 at the moment, as it seems pretty difficult to get 3.0 working on Debian. Anyway, the example I'm trying to do is the following: http://developer.gnome.org/gtkmm-tutorial/2.24/sec-helloworld.html.en . It compiles fine and it works well, but when I close it, valgrind reports a lot of leaks, something like this (after clicking the button once):

==4254== Memcheck, a memory error detector ==4254== Copyright (C) 2002-2010, and GNU GPL'd, by Julian Seward et al. ==4254== Using Valgrind-3.6.0.SVN-Debian and LibVEX; rerun with -h for copyright info ==4254== Command: ./bin/jmb ==4254== Hello World ==4254== ==4254== HEAP SUMMARY: ==4254== in use at exit: 942,940 bytes in 7,968 blocks ==4254== total heap usage: 14,191 allocs, 6,223 frees, 3,272,961 bytes allocated ==4254== ==4254== LEAK SUMMARY: ==4254== definitely lost: 2,620 bytes in 6 blocks ==4254== indirectly lost: 5,936 bytes in 187 blocks ==4254== possibly lost: 358,625 bytes in 1,775 blocks ==4254== still reachable: 575,759 bytes in 6,000 blocks ==4254== suppressed: 0 bytes in 0 blocks ==4254== Rerun with --leak-check=full to see details of leaked memory ==4254== ==4254== For counts of detected and suppressed errors, rerun with: -v ==4254== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 9 from 9) 

This will happen if I stop the program using Cc or click the close window button (in this case I have to use Shift-Meta-C to close the window due to the window manager). Is this an expected behavior, such as a MySQL connector, that prevents this last pointer from being deleted? In this case, it seems that most of the memory cannot be "allowed" for deletion? Or did I just miss something really simple?

For the sake of this, here is my code: (Changed by HelloWorld for testing) main.cpp:

 #include "gui/Test.hpp" #include <gtkmm/main.h> int main(int argc, char **argv) { Gtk::Main kit(argc, argv); Test t; Gtk::Main::run(t); return 0; } 

Test.hpp:

 #pragma once #include <gtkmm/button.h> #include <gtkmm/window.h> class Test : public Gtk::Window { public: Test(); virtual ~Test(); protected: //Signal handlers: void on_button_clicked(); //Member widgets: Gtk::Button m_button; }; 

test.cpp:

 #include "Test.hpp" #include <iostream> Test::Test() : m_button("Hello World") // creates a new button with label "Hello World". { // Sets the border width of the window. set_border_width(10); // When the button receives the "clicked" signal, it will call the // on_button_clicked() method defined below. m_button.signal_clicked().connect(sigc::mem_fun(*this, &Test::on_button_clicked)); // This packs the button into the Window (a container). add(m_button); // The final step is to display this newly created widget... m_button.show(); } Test::~Test() { } void Test::on_button_clicked() { std::cout << "Hello World" << std::endl; } 

Thanks in advance!

Answer 1

The leak is not from your code, since you do not have dynamic memory allocations. Since you defined your Test t variable on the stack, rather than dynamically, it will be deleted when it goes out of scope. This will be when the main () function completes, which is actually before the completion of the entire program. In addition, the Test class does not have direct dynamic memory allocations. By mentioning direct, I mean directly in this class, but not in the attributes (gtk, etc.) that it contains.

To demonstrate that your Test instance is indeed being deleted, you can put printf in the destructor. You should see the output when the application exits.

Even if you defined / created an instance of Test dynamically, you should get used to always delete everything that you create. In this case, it is just memory, but it can be more valuable resources, such as database connections, file system resources, or other logic that must be executed upon exit.

It is possible that Valgrind will give you stack traces of memory leaks, I'm sure you will see that they are in the gtk code. If so, I would think about creating an error. I would not be too worried about memory still reachable (actually it is not a leak), but instead look definitely lost and indirectly lost .

Answer 2

Assuming Gtk is not a memory leak, the output you posted may be compatible with this assumption.

The fact that some memory is still available for program exit is not the same as a memory leak.

Does the following program leak memory?

 int main() { int* a = new int[10]; return 0; } 

It may seem, but the full answer should be: it depends!

If we do not use MS / DOS, and “a” is required until the very end of the program, this can hardly detect a leak ... we can say that the programmer has left the responsibility for cleaning up to the main operating system.

In addition, Valgrind is a very good and useful tool, but it can report false positives.

Answer 3

Set the G_SLICE environment variable to reconfigure the GSlice memory allocator.

 G_SLICE=always-malloc ./your_application 

See this post for more details.