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.
[EMAIL PROTECTED]:~$ 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.
[EMAIL PROTECTED]:~$ 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.
[EMAIL PROTECTED]:~$ 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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]>:
>>
>> 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 <[EMAIL PROTECTED]>
>> 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
>> > [email protected]
>> > http://mail.gnome.org/mailman/listinfo/gtkmm-list
>> >
>> >
>> _______________________________________________
>> gtkmm-list mailing list
>> [email protected]
>> http://mail.gnome.org/mailman/listinfo/gtkmm-list
>
>
_______________________________________________
gtkmm-list mailing list
[email protected]
http://mail.gnome.org/mailman/listinfo/gtkmm-list
