Re: memory leaks in OptionEntry::add_entry

[Murray Cumming <murrayc murrayc com>]

On Thu, 2008-04-24 at 19:50 +0300, Ionutz Borcoman wrote:
> Hi,
> 
> I'm trying to see how to use the Glib::OpenEntry.
> 
> When I compile and run the attached program, valgrind complains on memory 
> leaks when I use "OptionGroup::add_entry (const OptionEntry& entry, 
> vecustrings& arg)".
> 
> Is this a real leak?
> 
> $ valgrind --leak-check=full options -b -s xxx -v aaa
> ...
> ==25883== 16 (12 direct, 4 indirect) bytes in 2 blocks are definitely lost in 
> loss record 15 of 71
> ==25883==    at 0x4022AB8: malloc (vg_replace_malloc.c:207)
> ==25883==    by 0x4A0471C: g_malloc (in /usr/lib/libglib-2.0.so.0.1600.3)
> ==25883==    by 0x4959A9C: 
> Glib::OptionGroup::CppOptionEntry::set_c_arg_default(void*) 
> (in /usr/lib/libglibmm-2.4.so.1.0.24)
> ==25883==    by 0x4959F43: 
> Glib::OptionGroup::add_entry_with_wrapper(Glib::OptionEntry const&, 
> GOptionArg, void*) (in /usr/lib/libglibmm-2.4.so.1.0.24)
> ==25883==    by 0x495A142: Glib::OptionGroup::add_entry(Glib::OptionEntry 
> const&, std::vector<Glib::ustring, std::allocator<Glib::ustring> >&) 
> (in /usr/lib/libglibmm-2.4.so.1.0.24)
> ==25883==    by 0x804A688: main (main.cc:40)
> ==25883==
> ...
> ==25883== LEAK SUMMARY:
> ==25883==    definitely lost: 12 bytes in 2 blocks.
> ==25883==    indirectly lost: 4 bytes in 1 blocks.
> ==25883==      possibly lost: 25,976 bytes in 41 blocks.
> ==25883==    still reachable: 177,160 bytes in 3,359 blocks.
> ==25883==         suppressed: 0 bytes in 0 blocks.
> ==25883== Reachable blocks (those to which a pointer was found) are not shown.
> ==25883== To see them, rerun with: --leak-check=full --show-reachable=yes
> 
> Are the 'possibly lost' and 'still reachable' important? If not, can they be 
> suppressed somehow?

I made a change to maybe deal with something similar recently. Are you
using the latest glibmm version?

-- 
murrayc murrayc com
www.murrayc.com
www.openismus.com