[Users] [Bug 3155] Memory leaks found by Valgrind in a9065aec26499a0e1294c73b6d9e6f039976521e

[noreply at thewildbeast.co.uk]

http://www.thewildbeast.co.uk/claws-mail/bugzilla/show_bug.cgi?id=3155

--- Comment #4 from Deweloper <deweloper at wp.pl> ---
I've upgraded to claws-mail 8880d1a9996875e5cb872509de1d47c22e0b9b04 and still
see leaks like those you previously commented with "weird. Will investigate
later.":

==00:00:52:10.981 2787== 19,736 (13,020 direct, 6,716 indirect) bytes in 3
blocks are definitely lost in loss record 17,264 of 17,329
==00:00:52:10.981 2787==    at 0x40087BA: calloc (in
/usr/lib/valgrind/vgpreload_memcheck-x86-linux.so)
==00:00:52:10.981 2787==    by 0x4806B529: g_malloc0 (gmem.c:134)
==00:00:52:10.981 2787==    by 0x80DD1C9: imap_session_get (imap.c:1180)
==00:00:52:10.981 2787==    by 0x80DED0F: imap_scan_required (imap.c:4712)
==00:00:52:10.981 2787==    by 0x80D4439: folderview_check_new
(folderview.c:1145)
==00:00:52:10.981 2787==    by 0x80EDF88: inc_all_account_mail (inc.c:362)
==00:00:52:10.981 2787==    by 0x80EEB40: defer_check_all (main.c:314)
==00:00:52:10.981 2787==    by 0x48066261: g_timeout_dispatch (gmain.c:4451)
==00:00:52:10.981 2787==    by 0x48065555: g_main_context_dispatch
(gmain.c:3066)
==00:00:52:10.981 2787==    by 0x4806591F: g_main_context_iterate.isra.23
(gmain.c:3713)
==00:00:52:10.981 2787==    by 0x48065DC2: g_main_loop_run (gmain.c:3907)
==00:00:52:10.981 2787==    by 0x454E66FF: gtk_main (gtkmain.c:1257)
==00:00:52:10.981 2787== 

==00:00:56:04.218 2831== 19,736 (13,020 direct, 6,716 indirect) bytes in 3
blocks are definitely lost in loss record 17,252 of 17,317
==00:00:56:04.218 2831==    at 0x40087BA: calloc (in
/usr/lib/valgrind/vgpreload_memcheck-x86-linux.so)
==00:00:56:04.218 2831==    by 0x4806B529: g_malloc0 (gmem.c:134)
==00:00:56:04.219 2831==    by 0x80DD1C9: imap_session_get (imap.c:1180)
==00:00:56:04.219 2831==    by 0x80DED0F: imap_scan_required (imap.c:4712)
==00:00:56:04.219 2831==    by 0x80D4439: folderview_check_new
(folderview.c:1145)
==00:00:56:04.219 2831==    by 0x80EDF88: inc_all_account_mail (inc.c:362)
==00:00:56:04.219 2831==    by 0x80EEB40: defer_check_all (main.c:314)
==00:00:56:04.219 2831==    by 0x48066261: g_timeout_dispatch (gmain.c:4451)
==00:00:56:04.219 2831==    by 0x48065555: g_main_context_dispatch
(gmain.c:3066)
==00:00:56:04.219 2831==    by 0x4806591F: g_main_context_iterate.isra.23
(gmain.c:3713)
==00:00:56:04.219 2831==    by 0x48065DC2: g_main_loop_run (gmain.c:3907)
==00:00:56:04.219 2831==    by 0x454E66FF: gtk_main (gtkmain.c:1257)
==00:00:56:04.219 2831== 

Looking at imap_session_get() in imap.c:989 I think I can see two paths which
lead to loosing a valid session pointer.

1. Let's assume that rfolder->session = NULL @1017 so session =
imap_session_new() executes @1032;
the new session is obviously not-yet-authenticated so we branch to
imap_session_authenticate() @1042, what fails with a fatal error.
In such case imap_safe_destroy(session) is not called but the session pointer
is also not being stored anywhere.

2. If imap_cmd_noop(session) @1067 fails with a fatal error, pointer to the old
session (held in rfolder->session and local variable "session") is being lost
(replaced with a newly allocated one) without a call to imap_safe_destroy().

It seems that in case of fatal errors imap_handle_error() internally calls
imap_disc_session_destroy(), but this one doesn't free any memory.

-- 
You are receiving this mail because:
You are the assignee for the bug.