When executing NetRemoteTOD and NetApiBufferFree in a loop the application leaks ca. 256KiB of memory for each cycle. Note that this leak does not occur on the first cycle. Here is what valgrind says for 10 repetitions: ==5035== 1,180,233 bytes in 9 blocks are possibly lost in loss record 7 of 8 ==5035== at 0x482204A: malloc (vg_replace_malloc.c:195) ==5035== by 0x493060D: cli_negprot_done (cliconnect.c:1785) ==5035== by 0x4907D04: _tevent_req_notify_callback (tevent_req.c:124) ==5035== by 0x4907D33: tevent_req_finish (tevent_req.c:133) ==5035== by 0x4907D51: _tevent_req_done (tevent_req.c:148) ==5035== by 0x4961AEB: cli_smb_received (async_smb.c:715) ==5035== by 0x4907D04: _tevent_req_notify_callback (tevent_req.c:124) ==5035== by 0x4907D33: tevent_req_finish (tevent_req.c:133) ==5035== by 0x4907D51: _tevent_req_done (tevent_req.c:148) ==5035== by 0x4960370: read_smb_done (async_smb.c:93) ==5035== by 0x4907D04: _tevent_req_notify_callback (tevent_req.c:124) ==5035== by 0x4907D33: tevent_req_finish (tevent_req.c:133) ==5035== ==5035== 1,180,233 bytes in 9 blocks are possibly lost in loss record 8 of 8 ==5035== at 0x482204A: malloc (vg_replace_malloc.c:195) ==5035== by 0x4930628: cli_negprot_done (cliconnect.c:1786) ==5035== by 0x4907D04: _tevent_req_notify_callback (tevent_req.c:124) ==5035== by 0x4907D33: tevent_req_finish (tevent_req.c:133) ==5035== by 0x4907D51: _tevent_req_done (tevent_req.c:148) ==5035== by 0x4961AEB: cli_smb_received (async_smb.c:715) ==5035== by 0x4907D04: _tevent_req_notify_callback (tevent_req.c:124) ==5035== by 0x4907D33: tevent_req_finish (tevent_req.c:133) ==5035== by 0x4907D51: _tevent_req_done (tevent_req.c:148) ==5035== by 0x4960370: read_smb_done (async_smb.c:93) ==5035== by 0x4907D04: _tevent_req_notify_callback (tevent_req.c:124) ==5035== by 0x4907D33: tevent_req_finish (tevent_req.c:133) How to reproduce: ./configure --with-libnetapi --with-libsmbclient --with-winbind --with-wbclient --enable-debug Use the example from lib/netapi/examples/server/remote_tod.c with the following patch applied. --- /root/samba-3.5.4/source3/lib/netapi/examples/server/remote_tod.c 2010-06-18 14:01:04.000000000 +0200 +++ ./remote_tod.c 2010-09-06 21:30:14.000000000 +0200 @@ -36,6 +36,7 @@ poptContext pc; int opt; + int i; struct poptOption long_options[] = { POPT_AUTOHELP @@ -62,17 +63,19 @@ /* NetRemoteTOD */ - - status = NetRemoteTOD(hostname, - (uint8_t **)&tod); - if (status != 0) { - printf("NetRemoteTOD failed with: %s\n", - libnetapi_get_error_string(ctx, status)); - } else { - printf("%d-%d-%d %d:%d:%d\n", - tod->tod_day, tod->tod_month, tod->tod_year, - tod->tod_hours, tod->tod_mins, tod->tod_secs); - NetApiBufferFree(tod); + for (i = 0; i < 10; ++i) + { + status = NetRemoteTOD(hostname, + (uint8_t **)&tod); + if (status != 0) { + printf("NetRemoteTOD failed with: %s\n", + libnetapi_get_error_string(ctx, status)); + } else { + printf("%d-%d-%d %d:%d:%d\n", + tod->tod_day, tod->tod_month, tod->tod_year, + tod->tod_hours, tod->tod_mins, tod->tod_secs); + NetApiBufferFree(tod); + } } out:
Created attachment 5947 [details] Full valgrind output
In case this helps recognizing the problem: Calling libnetapi_shutdown_cm(ctx); pipe_connections = NULL; after each cycle prevents the leak. Obviously this is no solution.
Created attachment 5948 [details] patch which fixes the leak for me The patch adds proper deallocation of the linked list in libnetapi_shutdown_cm and a call to libnetapi_shutdown_cm after each Net* function. I don't habe enough knowledge about samba internals to be sure this is the right way to fix things. I'm using this as a temporary workaround.
reassigning to myself.
This patch is a bit inefficient I think. The proper fix would be to cache the cli_state structures in the libnetapi_ctx. Günther, what do you think? Volker
Created attachment 5971 [details] patch for 3.5
Vincent, we need to address this differently, could you please try the attached patch and see if it works for you ?
Created attachment 5974 [details] Patch for 3.5 A patch on top of Günthers one.
Comment on attachment 5971 [details] patch for 3.5 Together with my patch that followed, this solves the problem
Comment on attachment 5974 [details] Patch for 3.5 looks fine.
Karolin, please add to 3.5.x and 3.4.x as well (both patches apply cleanly), thanks.
Sorry, I can not test before next week. I will report back then if all leaks have been resolved.
(In reply to comment #11) > Karolin, please add to 3.5.x and 3.4.x as well (both patches apply cleanly), > thanks. > Pushed both patches to v3-5-test. Applying the first patch to v3-4-test fails with: Applying: s3-libnetapi: Fix Bug #7665, memory leak in netapi connection manager. error: patch failed: source3/lib/netapi/cm.c:189 error: source3/lib/netapi/cm.c: patch does not apply Patch failed at 0001 s3-libnetapi: Fix Bug #7665, memory leak in netapi connection manager. Re-assigning to Günther to provide a patch for v3-4-test.
(In reply to comment #7) > Vincent, we need to address this differently, could you please try the attached > patch and see if it works for you ? > Applying both of your patches to 3.5.4 fixes the problem. Meanwhile ive discovered another realted bug. There is a growing memory leak as well. Please see the attached massif output file.
Created attachment 5990 [details] Massif output
Thanks! Investigating. Volker
Created attachment 5994 [details] Patch for 3.5 This is what I've pushed to master and 3.6. It fixes that memleak for me. Thanks for persisting :-) Volker
Created attachment 5995 [details] Patch for 3.5 Had forgotten the "git am --resolved"... The previous version still contained conflicts from the merge from master. Sorry, Volker
(In reply to comment #17) > Created an attachment (id=5994) [details] > Patch for 3.5 > > This is what I've pushed to master and 3.6. It fixes that memleak for me. > > Thanks for persisting :-) > > Volker > Hi Volker, i just repeated the massif test with this patch. All is fine now! Thank you very much for adressing this problem. Regards, Vincent
Comment on attachment 5995 [details] Patch for 3.5 yep, looks fine. thanks!
Karolin, please add to 3.5
Pushed to v3-5-test. Closing out bug report. Thanks!