1., wbcAuthenticateUserEx() returns a 'struct wbcAuthUserInfo *', but there is no way to free it (plain free() won't do it if samba was compiled with libtalloc support). 2., wbcAuthenticateUserEx() leaks response->extra_data.data of it local response structures.
Created attachment 3449 [details] fixes mem leaks of wbcAuthenticateUserEx
2. might be valid. But 1.: Doesn't wbcFreeMemory work for you? Volker
(In reply to comment #2) > 2. might be valid. And only half of it: freeing 'sep_response' is missing, but 'response' is freed correctly in 3.2.0. (Sorry for the dup.) > But 1.: Doesn't wbcFreeMemory work for you? Well, certainly it does, but then everyone who calls wbcAuthenticateUserEx with non-NULL info should implement wbc_free_auth_info in his client program. However, if I'm the only one doing so, it may go to client-space as well :).
No, you're missing the point of how talloc() works. You don't need to do the free on every part of the structure. You just call wbcFreeMemory() on the returned struct wbcAuthUserInfo pointer and you're done. I don't think the WINBINDD_INFO call allocates any extra data, so it's safe in this usage. I don't see any memory leaks here. Have you tested with valgrind to be sure ? Jeremy.
(In reply to comment #4) > No, you're missing the point of how talloc() works. You don't need to do the > free on every part of the structure. You are right, I should've read all the manuals first :(. This libtalloc is really a bit more than just-another-malloc-wrapper... > I don't think the WINBINDD_INFO call allocates any extra data, so it's safe in > this usage. I don't see any memory leaks here. Have you tested with valgrind > to be sure ? It only leaked (naturally) if the returned struct wasn't freed at all. So, issue #1 is just completely invalid, clean case of PEBKAC on my part, sorry.
So, can we close this bug now? Volker
Done.