valgrind reported this memory leak to me in testing an application that
I'm building:
==1807969== 24 bytes in 1 blocks are definitely lost in loss record 2 of 12
==1807969== at 0x4849464: calloc (vg_replace_malloc.c:1328)
==1807969== by 0x160F2F: nl_addr_alloc (addr.c:184)
==1807969== by 0x160F2F: nl_addr_build (addr.c:215)
==1807969== by 0x15CEF1: xfrmnl_sa_parse (sa.c:693)
==1807969== by 0x18F95D: parse_sa (xfrm_monitor.c:82)
==1807969== by 0x18FC5A: parse_nlmsg (xfrm_monitor.c:170)
==1807969== by 0x18FC5A: xfrm_cb (xfrm_monitor.c:181)
==1807969== by 0x169D21: nl_cb_call (netlink.h:138)
==1807969== by 0x169D21: recvmsgs (nl.c:868)
==1807969== by 0x16A42C: nl_recvmsgs_report (nl.c:1051)
==1807969== by 0x16A42C: nl_recvmsgs (nl.c:1075)
==1807969== by 0x16A42C: nl_recvmsgs_default (nl.c:1089)
==1807969== by 0x18FD6F: monitor_xfrm (xfrm_monitor.c:233)
==1807969== by 0x49D8B19: start_thread (pthread_create.c:443)
==1807969== by 0x4A5C8F3: clone (clone.S:100)
when calling xfrmnl_sa_parse, we accidentally get a refcount of 2 on the
selector source and destination addresses. The nl_addr_build calls for
these addresses set the count to one, and the subsequent calls to
xfrmnl_selset[s|d]addr increase the reference count to two.
One of the references is dropped when we call xfrmnl_sa_put, which calls
down through xfrmnl_sa_free_data->xfrmnl_sel_put->nl_addr_put(), but the
other reference count is leaked, leading to the above leak of both the
saddr and daddr pointers.
Not sure if this is the ideal fix, but it works for me, we just drop
the refrence count incremented by the call to set_[s|d]addr.
thom311
commented
2 years ago
valgrind reported this memory leak to me in testing an application that I'm building:
==1807969== 24 bytes in 1 blocks are definitely lost in loss record 2 of 12 ==1807969== at 0x4849464: calloc (vg_replace_malloc.c:1328) ==1807969== by 0x160F2F: nl_addr_alloc (addr.c:184) ==1807969== by 0x160F2F: nl_addr_build (addr.c:215) ==1807969== by 0x15CEF1: xfrmnl_sa_parse (sa.c:693) ==1807969== by 0x18F95D: parse_sa (xfrm_monitor.c:82) ==1807969== by 0x18FC5A: parse_nlmsg (xfrm_monitor.c:170) ==1807969== by 0x18FC5A: xfrm_cb (xfrm_monitor.c:181) ==1807969== by 0x169D21: nl_cb_call (netlink.h:138) ==1807969== by 0x169D21: recvmsgs (nl.c:868) ==1807969== by 0x16A42C: nl_recvmsgs_report (nl.c:1051) ==1807969== by 0x16A42C: nl_recvmsgs (nl.c:1075) ==1807969== by 0x16A42C: nl_recvmsgs_default (nl.c:1089) ==1807969== by 0x18FD6F: monitor_xfrm (xfrm_monitor.c:233) ==1807969== by 0x49D8B19: start_thread (pthread_create.c:443) ==1807969== by 0x4A5C8F3: clone (clone.S:100)
when calling xfrmnl_sa_parse, we accidentally get a refcount of 2 on the selector source and destination addresses. The nl_addr_build calls for these addresses set the count to one, and the subsequent calls to xfrmnl_selset[s|d]addr increase the reference count to two.
One of the references is dropped when we call xfrmnl_sa_put, which calls down through xfrmnl_sa_free_data->xfrmnl_sel_put->nl_addr_put(), but the other reference count is leaked, leading to the above leak of both the saddr and daddr pointers.
Not sure if this is the ideal fix, but it works for me, we just drop the refrence count incremented by the call to set_[s|d]addr.
Signed-off-by: Neil Horman nhorman@tuxdriver.com