Re: Memory leaks

I have dug into this a bit, and found a likely culprit:

The hash table is being created at droute.c:  107

     new_path->properties = g_hash_table_new_full ((GHashFunc)str_pair_hash,
                                                   str_pair_equal,
                                                   g_free,
                                                   NULL);

Sure enough, the value deallocator is set to NULL.  I am sure there is a 
good reason why it is not currently set to g_free, so I don't think that 
would be a fix.  (although, in this particular memory leak situation, 
the "pair" is being allocated with g_new, so using g_free would work).

Perhaps, the values could be wrapped in Glib::RefPtr or std::shared_ptr, 
or even the simpler std::unique_ptr.

I have CC'd the at-spi group, to get their feedback.



On 10/02/2013 10:47 PM, Andrew Potter wrote:
> 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 <[email protected]> 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
>> [email protected]
>> https://mail.gnome.org/mailman/listinfo/gtkmm-list
>>

_______________________________________________
gtkmm-list mailing list
[email protected]
https://mail.gnome.org/mailman/listinfo/gtkmm-list