GNOME Bugzilla – Bug 702025
source_registry_authenticate_authenticate_cb() leaks a string.
Last modified: 2013-08-09 14:22:56 UTC
==21714== 40 (24 direct, 16 indirect) bytes in 1 blocks are definitely lost in loss record 3,076 of 7,013 ==21714== at 0x4A06409: malloc (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so) ==21714== by 0x376804D93E: g_malloc (gmem.c:159) ==21714== by 0x37680634ED: g_slice_alloc (gslice.c:1003) ==21714== by 0x3768066E02: g_string_sized_new (gstring.c:126) ==21714== by 0x3768067452: g_string_new (gstring.c:158) ==21714== by 0x3DDFE48EAA: source_registry_authenticate_authenticate_cb (e-source-registry.c:1837) ==21714== by 0x3CFC805CFB: ffi_call_unix64 (in /usr/lib64/libffi.so.6.0.1) ==21714== by 0x3CFC80562B: ffi_call (in /usr/lib64/libffi.so.6.0.1) ==21714== by 0x3CFCC10267: g_cclosure_marshal_generic (gclosure.c:1454) ==21714== by 0x3CFCC0FA27: g_closure_invoke (gclosure.c:777) ==21714== by 0x3CFCC20A3C: signal_emit_unlocked_R (gsignal.c:3584) ==21714== by 0x3CFCC278D0: g_signal_emitv (gsignal.c:3059)
maybe related? Probably not but can at least be looked at at the same time. I'm opening enough bugs already... ==21714== at 0x4A08121: calloc (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so) ==21714== by 0x376804D996: g_malloc0 (gmem.c:189) ==21714== by 0x3768025A24: g_get_language_names (gcharset.c:562) ==21714== by 0x376803E98B: g_key_file_init (gkeyfile.c:571) ==21714== by 0x376804061C: g_key_file_new (gkeyfile.c:628) ==21714== by 0x3D04434C4A: gcr_secret_exchange_begin (in /usr/lib64/libgcr-base-3.so.1.0.0) ==21714== by 0x3DDFE4B48A: e_source_registry_authenticate_sync (e-source-registry.c:2073) ==21714== by 0xF95224D: caldav_do_open (e-cal-backend-caldav.c:2904) ==21714== by 0x3DE0617278: cal_backend_open (e-cal-backend-sync.c:559) ==21714== by 0x3DE061FE15: operation_thread (e-data-cal.c:504) ==21714== by 0x376806CBE5: g_thread_pool_thread_proxy (gthreadpool.c:309) ==21714== by 0x376806C224: g_thread_proxy (gthread.c:798)
And I'm going to throw this one into the same bug too, because it also has 'authenticator' in there somewhere and it's going to be hard to find if it *isn't* related... ==21714== 384 (48 direct, 336 indirect) bytes in 1 blocks are definitely lost in loss record 6,313 of 7,013 ==21714== at 0x4A08121: calloc (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so) ==21714== by 0x376804D996: g_malloc0 (gmem.c:189) ==21714== by 0x3DE023CD26: e_dbus_authenticator_proxy_g_signal (e-dbus-authenticator.c:1030) ==21714== by 0x3CFC805CFB: ffi_call_unix64 (in /usr/lib64/libffi.so.6.0.1) ==21714== by 0x3CFC80562B: ffi_call (in /usr/lib64/libffi.so.6.0.1) ==21714== by 0x3CFCC10267: g_cclosure_marshal_generic (gclosure.c:1454) ==21714== by 0x3CFCC0FA27: g_closure_invoke (gclosure.c:777) ==21714== by 0x3CFCC207FA: signal_emit_unlocked_R (gsignal.c:3622) ==21714== by 0x3CFCC28828: g_signal_emit_valist (gsignal.c:3328) ==21714== by 0x3CFCC28A71: g_signal_emit (gsignal.c:3384) ==21714== by 0x3CFD0C308B: on_signal_received (gdbusproxy.c:927) ==21714== by 0x3CFD0B3B64: emit_signal_instance_in_idle_cb (gdbusconnection.c:3715)
Looks like the one in comment #1. Do feel free to open separate bugs if I was wrong to bundle these together. I'm mostly just going through a huge valgrind log and trying to make some vague attempt to triage what I find there... ==21714== 752 (64 direct, 688 indirect) bytes in 4 blocks are definitely lost in loss record 6,493 of 7,013 ==21714== at 0x4A08121: calloc (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so) ==21714== by 0x376804D996: g_malloc0 (gmem.c:189) ==21714== by 0x3768025A24: g_get_language_names (gcharset.c:562) ==21714== by 0x3768041E4C: g_key_file_get_locale_string (gkeyfile.c:2103) ==21714== by 0x3DDFE3B223: source_load_from_key_file (e-source.c:484) ==21714== by 0x3DDFE3BB0A: e_source_get_extension (e-source.c:2266) ==21714== by 0xCF7D730: e_cal_backend_ews_open (e-cal-backend-ews.c:629) ==21714== by 0x3DE061FE15: operation_thread (e-data-cal.c:504) ==21714== by 0x376806CBE5: g_thread_pool_thread_proxy (gthreadpool.c:309) ==21714== by 0x376806C224: g_thread_proxy (gthread.c:798) ==21714== by 0x3909607C52: start_thread (pthread_create.c:308) ==21714== by 0x39092F4ECC: clone (clone.S:113)
Comment 0 might be legitimate. Comment 1 and comment 3 are one-time allocations, not leaks. Comment 2 might be a one-time allocation as well, but that's coming from generated code (gdbus-codegen) and beyond our control in any case.
Hmm, comment 0 is either bogus or beyond our control. The GString being allocated on line 1837 is freed on line 1866 and there's no return statement between them. Also, the GString is being initialized with gcr_secret_exchange_get_secret(), which returns a "const gchar *". Don't see anything to do here.
(In reply to comment #5) > Don't see anything to do here. Neither do I. Closing.