Bug 7665 - Repeated use of NetRemoteTOD and NetApiBufferFree leaks memory heavily
Repeated use of NetRemoteTOD and NetApiBufferFree leaks memory heavily
Status: RESOLVED FIXED
Product: Samba 3.5
Classification: Unclassified
Component: Client Tools
3.5.4
x86 Linux
: P3 normal
: ---
Assigned To: Karolin Seeger
Samba QA Contact
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2010-09-06 14:32 UTC by Vincent Kessler
Modified: 2010-11-11 05:03 UTC (History)
0 users

See Also:


Attachments
Full valgrind output (5.61 KB, text/plain)
2010-09-06 15:04 UTC, Vincent Kessler
no flags Details
patch which fixes the leak for me (7.75 KB, patch)
2010-09-06 17:43 UTC, Vincent Kessler
no flags Details
patch for 3.5 (6.37 KB, patch)
2010-09-21 03:44 UTC, Guenther Deschner
vl: review+
Details
Patch for 3.5 (2.87 KB, patch)
2010-09-21 17:49 UTC, Volker Lendecke
gd: review+
Details
Massif output (255.63 KB, text/plain)
2010-09-29 08:53 UTC, Vincent Kessler
no flags Details
Patch for 3.5 (70.25 KB, patch)
2010-10-02 05:05 UTC, Volker Lendecke
no flags Details
Patch for 3.5 (69.44 KB, patch)
2010-10-02 05:23 UTC, Volker Lendecke
gd: review+
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Vincent Kessler 2010-09-06 14:32:09 UTC
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:
Comment 1 Vincent Kessler 2010-09-06 15:04:55 UTC
Created attachment 5947 [details]
Full valgrind output
Comment 2 Vincent Kessler 2010-09-06 16:16:37 UTC
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.
Comment 3 Vincent Kessler 2010-09-06 17:43:13 UTC
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.
Comment 4 Guenther Deschner 2010-09-07 01:33:33 UTC
reassigning to myself.
Comment 5 Volker Lendecke 2010-09-20 00:55:27 UTC
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
Comment 6 Guenther Deschner 2010-09-21 03:44:08 UTC
Created attachment 5971 [details]
patch for 3.5
Comment 7 Guenther Deschner 2010-09-21 03:45:15 UTC
Vincent, we need to address this differently, could you please try the attached patch and see if it works for you ?
Comment 8 Volker Lendecke 2010-09-21 17:49:31 UTC
Created attachment 5974 [details]
Patch for 3.5

A patch on top of Günthers one.
Comment 9 Volker Lendecke 2010-09-21 17:57:27 UTC
Comment on attachment 5971 [details]
patch for 3.5

Together with my patch that followed, this solves the problem
Comment 10 Guenther Deschner 2010-09-21 17:59:12 UTC
Comment on attachment 5974 [details]
Patch for 3.5

looks fine.
Comment 11 Guenther Deschner 2010-09-21 18:38:14 UTC
Karolin, please add to 3.5.x and 3.4.x as well (both patches apply cleanly), thanks.

Comment 12 Vincent Kessler 2010-09-22 09:19:34 UTC
Sorry, I can not test before next week.
I will report back then if all leaks have been resolved.
Comment 13 Karolin Seeger 2010-09-25 08:01:56 UTC
(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.
Comment 14 Vincent Kessler 2010-09-29 08:52:08 UTC
(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.
Comment 15 Vincent Kessler 2010-09-29 08:53:16 UTC
Created attachment 5990 [details]
Massif output
Comment 16 Volker Lendecke 2010-10-01 13:58:30 UTC
Thanks!

Investigating.

Volker
Comment 17 Volker Lendecke 2010-10-02 05:05:39 UTC
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
Comment 18 Volker Lendecke 2010-10-02 05:23:30 UTC
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
Comment 19 Vincent Kessler 2010-10-02 10:26:58 UTC
(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 20 Guenther Deschner 2010-10-07 13:47:46 UTC
Comment on attachment 5995 [details]
Patch for 3.5

yep, looks fine. thanks!
Comment 21 Guenther Deschner 2010-10-07 13:48:16 UTC
Karolin, please add to 3.5
Comment 22 Karolin Seeger 2010-11-11 05:03:52 UTC
Pushed to v3-5-test.
Closing out bug report.

Thanks!