You are using gtkmm correctly. This isn't a gtkmm bug but is in at-spi. I fixed a similar bug for them before (#688363). I'd suggest filing a bug report with a patch on product at-spi if you can.
On Wed, Oct 2, 2013 at 10:07 PM, Norman Goldstein <norm...@telus.net> wrote: > I have searched through the past year, and there are several posts about > memory leaks in gtkmm/gtk+. However, I am not clear as to what the > recommendation is. I am using gtkmm30 on fedora 18 x86 32-bit. > I built and ran a standard piece of sample code: > > #include <gtkmm.h> > int main(int argc, char *argv[]) > { > Glib::RefPtr<Gtk::Application> app = > Gtk::Application::create(argc, argv, > "org.gtkmm.examples.base"); > > Gtk::Window window; > window.set_default_size(200, 200); > > return app->run(window); > }// main > > ***** Is there a clean-up routine I should also be invoking? ******** > > Valgrind gave the following summary: > > ==24123== LEAK SUMMARY: > ==24123== definitely lost: 280 bytes in 28 blocks > ==24123== indirectly lost: 0 bytes in 0 blocks > ==24123== possibly lost: 747,922 bytes in 6,535 blocks > ==24123== still reachable: 413,852 bytes in 7,213 blocks > ==24123== suppressed: 0 bytes in 0 blocks > ==24123== Reachable blocks (those to which a pointer was found) are not > shown. > ==24123== To see them, rerun with: --leak-check=full --show-reachable=yes > ==24123== > ==24123== For counts of detected and suppressed errors, rerun with: -v > ==24123== ERROR SUMMARY: 1085 errors from 1085 contexts (suppressed: 0 from > 0) > > Here is the first "definitely lost" report: > > ==24123== 8 bytes in 1 blocks are definitely lost in loss record 1,936 of > 7,107 > ==24123== at 0x4008FAF: malloc > (/builddir/build/BUILD/valgrind-3.8.1/coregrind/m_replacemalloc/vg_replace_malloc.c:270) > ==24123== by 0x44FF50DB: standard_malloc > (/usr/src/debug/glib-2.34.2/glib/gmem.c:85) > ==24123== by 0x44FF5481: g_malloc > (/usr/src/debug/glib-2.34.2/glib/gmem.c:159) > ==24123== by 0x476A8C06: droute_path_add_interface > (/usr/src/debug/at-spi2-atk-2.6.2/droute/droute.c:234) (<=================) > ==24123== by 0x476B0845: spi_initialize_selection > (/usr/src/debug/at-spi2-atk-2.6.2/atk-adaptor/adaptors/selection-adaptor.c:262) > ==24123== by 0x476A333D: atk_bridge_adaptor_init > (/usr/src/debug/at-spi2-atk-2.6.2/atk-adaptor/bridge.c:907) > ==24123== by 0x41D4C3C2: _gtk_accessibility_init > (/usr/src/debug/gtk+-3.6.4/gtk/a11y/gail.c:831) > ==24123== by 0x41BAA546: post_parse_hook > (/usr/src/debug/gtk+-3.6.4/gtk/gtkmain.c:733) > ==24123== by 0x44FFB429: g_option_context_parse > (/usr/src/debug/glib-2.34.2/glib/goption.c:2001) > ==24123== by 0x41BAAAE7: gtk_parse_args > (/usr/src/debug/gtk+-3.6.4/gtk/gtkmain.c:952) > ==24123== by 0x41BAAB73: gtk_init_check > (/usr/src/debug/gtk+-3.6.4/gtk/gtkmain.c:991) > ==24123== by 0x41BAABB3: gtk_init > (/usr/src/debug/gtk+-3.6.4/gtk/gtkmain.c:1046) > > I installed the debuginfo packages to get the source file information. > The leak is occurring at droute.c (indicated by the arrow, above): > > pair = g_new (PropertyPair, 1); //<===== Line 234 > pair->get = properties->get; > pair->set = properties->set; > g_hash_table_insert (path->properties, str_pair_new (itf, prop), > pair); //<====== > > The first arrow is where "pair" is allocated. It gets stored into a hash > table at the 2nd arrow. > Either there is a duplicate insertion that is not being managed (deleting > the original insertion), or > the table is not being destroyed, or it is being destroyed but not managing > its data. > > Most likely, I don't know the clean way of shutting down a gtkmm/gtk+ > session. > > > > > > > _______________________________________________ > gtkmm-list mailing list > gtkmm-list@gnome.org > https://mail.gnome.org/mailman/listinfo/gtkmm-list > _______________________________________________ gtkmm-list mailing list gtkmm-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtkmm-list