Re: free dialog memory

["John Hobbs" <john velvetcache org>]

Posting to list.

You are right, on my OpenSuSE install it does not free, though when
you open the dialog again it doesn't add to the mem use either.
Interesting.

I ran it through valgrind a few different ways, this is what I got.

jmhobbs urd:~$ valgrind ./testing  # Open program, open dialog, close
dialog, exit.
<snip>
==10956== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 45 from 2)
==10956== malloc/free: in use at exit: 1,539,876 bytes in 27,300 blocks.
==10956== malloc/free: 130,477 allocs, 103,177 frees, 15,764,887 bytes
allocated.
==10956== For counts of detected errors, rerun with: -v
==10956== searching for pointers to 27,300 not-freed blocks.
==10956== checked 2,069,312 bytes.
==10956==
==10956== LEAK SUMMARY:
==10956==    definitely lost: 98,905 bytes in 3,463 blocks.
==10956==      possibly lost: 119,556 bytes in 130 blocks.
==10956==    still reachable: 1,321,415 bytes in 23,707 blocks.
==10956==         suppressed: 0 bytes in 0 blocks.
==10956== Rerun with --leak-check=full to see details of leaked memory.
jmhobbs urd:~$ valgrind ./testing   # Open program, exit.
<snip>
==10957== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 23 from 2)
==10957== malloc/free: in use at exit: 614,711 bytes in 10,763 blocks.
==10957== malloc/free: 43,264 allocs, 32,501 frees, 5,762,513 bytes allocated.
==10957== For counts of detected errors, rerun with: -v
==10957== searching for pointers to 10,763 not-freed blocks.
==10957== checked 1,048,936 bytes.
==10957==
==10957== LEAK SUMMARY:
==10957==    definitely lost: 38,389 bytes in 1,322 blocks.
==10957==      possibly lost: 72,588 bytes in 74 blocks.
==10957==    still reachable: 503,734 bytes in 9,367 blocks.
==10957==         suppressed: 0 bytes in 0 blocks.
==10957== Rerun with --leak-check=full to see details of leaked memory.
jmhobbs urd:~$ valgrind ./testing     # Open program, open dialog,
close dialog, open dialog, close dialog, exit.
<snip>
==10958== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 45 from 2)
==10958== malloc/free: in use at exit: 1,539,908 bytes in 27,301 blocks.
==10958== malloc/free: 134,308 allocs, 107,007 frees, 16,788,589 bytes
allocated.
==10958== For counts of detected errors, rerun with: -v
==10958== searching for pointers to 27,301 not-freed blocks.
==10958== checked 2,072,124 bytes.
==10958==
==10958== LEAK SUMMARY:
==10958==    definitely lost: 98,689 bytes in 3,453 blocks.
==10958==      possibly lost: 119,556 bytes in 130 blocks.
==10958==    still reachable: 1,321,663 bytes in 23,718 blocks.
==10958==         suppressed: 0 bytes in 0 blocks.
==10958== Rerun with --leak-check=full to see details of leaked memory.

Ideas anyone?

- John Hobbs

On Fri, Jul 18, 2008 at 2:23 PM, Jean-Loup Defaisse <jloupdef gmail com> wrote:
> take this little exemple (simplified version of an exemple of the doc):
>
>> #include <gtkmm.h>
>> #include <gtkmm/main.h>
>> #include <gtkmm/dialog.h>
>> #include <iostream>
>>
>> class ExampleWindow : public Gtk::Window
>> {
>> public:
>>     ExampleWindow() : m_Button_Info("Show Info MessageDialog")
>>     {
>>         set_title("Gtk::MessageDialog example");
>>         add(m_ButtonBox);
>>         m_ButtonBox.pack_start(m_Button_Info);
>>         m_Button_Info.signal_clicked().connect(sigc::mem_fun(*this,
>>
>> &ExampleWindow::on_button_info_clicked) );
>>         show_all_children();
>>     };
>>     ~ExampleWindow(){};
>>
>> protected:
>>     //Signal handlers:
>>     void on_button_info_clicked()
>>     {
>>         Gtk::MessageDialog dialog(*this, "This is an INFO MessageDialog");
>>         dialog.set_secondary_text("And this is the secondary text that
>> explains things.");
>>         dialog.run();
>>     };
>>     //Child widgets:
>>     Gtk::VButtonBox m_ButtonBox;
>>     Gtk::Button m_Button_Info;
>> };
>>
>> int main(int argc, char *argv[])
>> {
>>   Gtk::Main kit(argc, argv);
>>   ExampleWindow window;
>>   //Shows the window and returns when it is closed.
>>   Gtk::Main::run(window);
>>   return 0;
>> }
>
> the on_button_info_clicked() function correspond exactly the first solution
> you give me. but when you run this program, the memory increase when you
> click the button because a MessageDialog is created but the memory is not
> freed when you close it (except if this is a bug with my gtkmm installation)
> can you confirm that?
> Is there any way to force the memory to be freed by adding something after
> dialog.run(); for instance...
>
> Thanks in advance
>
>
> 2008/7/18 John Hobbs <john velvetcache org>:
>>
>> Maybe I'm not getting your question, but it should be done when it
>> leaves a context.
>>
>> void what::ever () {
>>  Dialog myDialog("My Dialog");
>>  myDialog.run();
>> }
>> // myDialog no longer exists.
>>
>> If you want to be able to close it from anywhere in it's parent
>> window, I would make it a pointer in the parent window class...
>> ...
>> private:
>>  Dialog * myDialog;
>> ...
>>
>> Then do like this...
>>
>> void dialogLauncherWindow::showDialog () {
>>  if(NULL != myDialog)
>>    return;
>>
>>  myDialog = new Dialog("My Dialog");
>>  myDialog->run();
>>  delete myDialog;
>>  myDialog = NULL;
>> }
>>
>> void dialogLauncherWindow::clickAButtonToCloseDialog () {
>>  if(NULL == myDialog)
>>    return;
>>
>>  myDialog->hide();
>> }
>>
>> I think all of that is valid code, I sort of just wrote it right here
>> in the email.  It's close at least.
>>
>> - John Hobbs
>>
>> On Fri, Jul 18, 2008 at 12:02 PM, Jean-Loup Defaisse <jloupdef gmail com>
>> wrote:
>> > Hello,
>> > How can i close a Dialog (of any type: MessageDialog, FileChooserDialog
>> > ..)
>> > and free the memory which it was using (not just hide the dialog). I
>> > can't
>> > find the answer on the web but there certainly is a simple solution.
>> >
>> > Thanks in advance.
>> >
>> > _______________________________________________
>> > gtkmm-list mailing list
>> > gtkmm-list gnome org
>> > http://mail.gnome.org/mailman/listinfo/gtkmm-list
>> >
>> >
>> _______________________________________________
>> gtkmm-list mailing list
>> gtkmm-list gnome org
>> http://mail.gnome.org/mailman/listinfo/gtkmm-list
>
>