On Mon, Mar 26, 2007 at 08:39:06PM +0100, Rúben Fonseca wrote: > Hi to all! > > I'm developping a app with GLib. Recently I've tryied to remove all the > memory leaks of the app, using valgrind with great success. > > However, there is still one small leak that I want to discuss with you. > > The funcion "g_get_user_config_dir" returns a "const gchar *". In the > docs it says that I should not try to free the returned string. > > But valgrind keeps telling me the memory allocated on > g_get_user_config_dir is lost. And any try to g_free the memory results > in a bad experience. > > Attached to this email (hope the attachement works) is the dump of the > valgrind showing the problem I'm having. Oops.. ataching now... > > So my question is, is g_get_user_config_dir really leaking? Or it is > just a Valgrind problem? Can I make it not to leak? > > Thank you for your support. > > Ruben > > -- > Will work for bandwidth > _______________________________________________ > gtk-devel-list mailing list > gtk-devel-list gnome org > http://mail.gnome.org/mailman/listinfo/gtk-devel-list -- Will work for bandwidth
==29884== Memcheck, a memory error detector. ==29884== Copyright (C) 2002-2006, and GNU GPL'd, by Julian Seward et al. ==29884== Using LibVEX rev 1658, a library for dynamic binary translation. ==29884== Copyright (C) 2004-2006, and GNU GPL'd, by OpenWorks LLP. ==29884== Using valgrind-3.2.1-Debian, a dynamic binary instrumentation framework. ==29884== Copyright (C) 2000-2006, and GNU GPL'd, by Julian Seward et al. ==29884== For more details, rerun with: -v ==29884== ==29884== Invalid read of size 8 ==29884== at 0x4015274: (within /lib/ld-2.5.so) ==29884== by 0x400A7CD: (within /lib/ld-2.5.so) ==29884== by 0x4006164: (within /lib/ld-2.5.so) ==29884== by 0x40084AB: (within /lib/ld-2.5.so) ==29884== by 0x400B98C: (within /lib/ld-2.5.so) ==29884== by 0x400D725: (within /lib/ld-2.5.so) ==29884== by 0x400C05B: (within /lib/ld-2.5.so) ==29884== by 0x401173C: (within /lib/ld-2.5.so) ==29884== by 0x400D725: (within /lib/ld-2.5.so) ==29884== by 0x401114A: (within /lib/ld-2.5.so) ==29884== by 0x5565B1F: (within /lib/libc-2.5.so) ==29884== by 0x400D725: (within /lib/ld-2.5.so) ==29884== by 0x5565C86: __libc_dlopen_mode (in /lib/libc-2.5.so) ==29884== by 0x55414D6: __nss_lookup_function (in /lib/libc-2.5.so) ==29884== by 0x5541584: (within /lib/libc-2.5.so) ==29884== by 0x54F7144: getpwnam_r (in /lib/libc-2.5.so) ==29884== by 0x580832F: (within /usr/lib/libglib-2.0.so.0.1200.11) ==29884== by 0x580942A: g_get_user_config_dir (in /usr/lib/libglib-2.0.so.0.1200.11) ==29884== by 0x402B98: cshare_config_new (settings.c:39) ==29884== by 0x402A07: main (main.c:47) ==29884== Address 0x403D628 is 16 bytes inside a block of size 17 alloc'd ==29884== at 0x4C207C9: malloc (vg_replace_malloc.c:149) ==29884== by 0x4008999: (within /lib/ld-2.5.so) ==29884== by 0x400B98C: (within /lib/ld-2.5.so) ==29884== by 0x400D725: (within /lib/ld-2.5.so) ==29884== by 0x400C05B: (within /lib/ld-2.5.so) ==29884== by 0x401173C: (within /lib/ld-2.5.so) ==29884== by 0x400D725: (within /lib/ld-2.5.so) ==29884== by 0x401114A: (within /lib/ld-2.5.so) ==29884== by 0x5565B1F: (within /lib/libc-2.5.so) ==29884== by 0x400D725: (within /lib/ld-2.5.so) ==29884== by 0x5565C86: __libc_dlopen_mode (in /lib/libc-2.5.so) ==29884== by 0x55414D6: __nss_lookup_function (in /lib/libc-2.5.so) ==29884== by 0x5541584: (within /lib/libc-2.5.so) ==29884== by 0x54F7144: getpwnam_r (in /lib/libc-2.5.so) ==29884== by 0x580832F: (within /usr/lib/libglib-2.0.so.0.1200.11) ==29884== by 0x580942A: g_get_user_config_dir (in /usr/lib/libglib-2.0.so.0.1200.11) ==29884== by 0x402B98: cshare_config_new (settings.c:39) ==29884== by 0x402A07: main (main.c:47) ==29884== ==29884== ERROR SUMMARY: 4 errors from 1 contexts (suppressed: 16 from 1) ==29884== malloc/free: in use at exit: 15,046 bytes in 59 blocks. ==29884== malloc/free: 200 allocs, 141 frees, 74,923 bytes allocated. ==29884== For counts of detected errors, rerun with: -v ==29884== searching for pointers to 59 not-freed blocks. ==29884== checked 219,264 bytes. ==29884== ==29884== ==29884== 292 (52 direct, 240 indirect) bytes in 1 blocks are definitely lost in loss record 5 of 13 ==29884== at 0x4C207C9: malloc (vg_replace_malloc.c:149) ==29884== by 0x55416F0: (within /lib/libc-2.5.so) ==29884== by 0x5541F7A: __nss_database_lookup (in /lib/libc-2.5.so) ==29884== by 0x685731F: ??? ==29884== by 0x6858786: ??? ==29884== by 0x54F7064: getpwnam_r (in /lib/libc-2.5.so) ==29884== by 0x580832F: (within /usr/lib/libglib-2.0.so.0.1200.11) ==29884== by 0x580942A: g_get_user_config_dir (in /usr/lib/libglib-2.0.so.0.1200.11) ==29884== by 0x402B98: cshare_config_new (settings.c:39) ==29884== by 0x402A07: main (main.c:47) ==29884== ==29884== LEAK SUMMARY: ==29884== definitely lost: 52 bytes in 1 blocks. ==29884== indirectly lost: 240 bytes in 10 blocks. ==29884== possibly lost: 0 bytes in 0 blocks. ==29884== still reachable: 14,754 bytes in 48 blocks. ==29884== suppressed: 0 bytes in 0 blocks. ==29884== Reachable blocks (those to which a pointer was found) are not shown. ==29884== To see them, rerun with: --show-reachable=yes
Attachment:
signature.asc
Description: Digital signature