On 13/02/11 04:43, John Emmas wrote:
FWIW I tracked sown the mechanism for suppressing leak detections in MSVC. Basically, you can set checkpoints and only display the leaks between two specified points. It might not be as flexible as the method used in Valgrind but it's one helluva lot easier. Here's how I modified my original code:-int main (int argc, char *argv[]) { Gtk::Main app (&argc,&argv); MainWindow mainWnd; // g_thread initialisation here mainWnd.set_title ("Hello World !"); _CrtMemState state; // These two _CrtMemCheckpoint (&state ); // lines added app.run ( mainWnd ); _CrtMemDumpAllObjectsSince (&state ); // Dumps the 'leaks' return; } As you can see, I've told the dumper to ignore memory allocated during my initialisation. This leaves me with around 80 leak reports, some of which are very likely due to my own code. And although I don't see any g_warnings when I run the app, some are probably down to similar entities that delayed their initialisation until after app.run(). So let's say that ultimately, I can get my list down to around 65 leaks. At least that's a lot more manageable than I was seeing before! Hopefully this might help anyone who finds himself in the same situation as me. I still think that some cleanup functionality would be better though. John _______________________________________________ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Seems a useful solution.. Thanks John _______________________________________________ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
