PR#207: Fixes remaining memory leaks -

gssproxy

#207 Fixes remaining memory leaks

Merged Nov 15, 2017 by cipherboy. Opened Aug 8, 2017 by cipherboy.

cipherboy/gssproxy fix_memory_leaks into master

cipherboy commented Aug 8, 2017

I believe there are still memory leaks in libverto (related to default contexts which call malloc)
but this fixes the remaining memory leaks in gssproxy given that libverto is fixed by verto_cleanup().
This is dependent upon a later verto-related pull request that provides verto_cleanup().

Could I get some help writing verto_cleanup() detection code? :)

cipherboy commented Aug 8, 2017

==29563==    definitely lost: 0 bytes in 0 blocks
==29563==    indirectly lost: 0 bytes in 0 blocks
==29563==    still reachable: 34,641 bytes in 66 blocks

(before I realized that verto_cleanup() needs to call module_close(record->dll);)

After adding that to verto_cleanup():

==29986== 2,048 (640 direct, 1,408 indirect) bytes in 1 blocks are definitely lost in loss record 46 of 48
==29986==    at 0x4C30A1E: calloc (vg_replace_malloc.c:711)
==29986==    by 0x8C07C89: ???
==29986==    by 0x8C0805A: ???
==29986==    by 0x86E0134: ???
==29986==    by 0x5B82F19: verto_convert_module (verto.c:912)
==29986==    by 0x5B8321F: verto_default (verto.c:522)
==29986==    by 0x406B2C: init_event_loop (gp_init.c:114)
==29986==    by 0x413480: main (gssproxy.c:241)
==29986== LEAK SUMMARY:
==29986==    definitely lost: 640 bytes in 1 blocks
==29986==    indirectly lost: 1,408 bytes in 21 blocks
==29986==      possibly lost: 0 bytes in 0 blocks
==29986==    still reachable: 29,739 bytes in 36 blocks
==29986==         suppressed: 0 bytes in 0 blocks

Edited Aug 8, 2017 by cipherboy

simo commented Aug 8, 2017

/lgtm

simo commented Aug 8, 2017

Hoever jenkins is not happy:
../../src/gssproxy.c: In function ‘main’:
../../src/gssproxy.c:303:5: error: implicit declaration of function ‘verto_cleanup’ [-Werror=implicit-function-declaration]
verto_cleanup();
^~~~~~~~~~~~~