[Freeswitch-users] Memory leak in mod_nibblebill or in ODBC core?

Rupa Schomaker rupa at rupa.com
Mon Apr 19 11:20:41 PDT 2010


I committed a change to free up the config vars at module shutdown.  Doesn't
fix your problem but should shut up valgrind for those allocations:

   3e600fb..ca9dfc3  master -> master
 .../applications/mod_nibblebill/mod_nibblebill.c   |   12 ++++++++++++
 1 files changed, 12 insertions(+), 0 deletions(-)


so if you update your git to at least version "ca9dfc3"  you'll have it.

On Mon, Apr 19, 2010 at 1:12 PM, Rupa Schomaker <rupa at rupa.com> wrote:

> Those strdups are probably easily fixed.  But...  THey are just in the
> module load, not as part of the module runtime.  So it is a one-time leak
> not a per-call or per-nibble leak.
>
> On Mon, Apr 19, 2010 at 12:48 PM, Sergey Okhapkin <
> sos at sokhapkin.dyndns.org> wrote:
>
>> Few unimportant records only:
>>
>> ==12476== 7 bytes in 1 blocks are still reachable in loss record 21 of 141
>> ==12476==    at 0x4026378: malloc (in /usr/lib/valgrind/x86-
>> linux/vgpreload_memcheck.so)
>> ==12476==    by 0x457B6CF: strdup (in /lib/libc-2.10.1.so)
>> ==12476==    by 0x7BECC00: mod_nibblebill_load (mod_nibblebill.c:132)
>>
>> ==12476== 7 bytes in 1 blocks are still reachable in loss record 22 of 141
>> ==12476==    at 0x4026378: malloc (in /usr/lib/valgrind/x86-
>> linux/vgpreload_memcheck.so)
>> ==12476==    by 0x457B6CF: strdup (in /lib/libc-2.10.1.so)
>> ==12476==    by 0x7BECD14: mod_nibblebill_load (mod_nibblebill.c:134)
>>
>> ==12476== 7 bytes in 1 blocks are still reachable in loss record 23 of 141
>> ==12476==    at 0x4026378: malloc (in /usr/lib/valgrind/x86-
>> linux/vgpreload_memcheck.so)
>> ==12476==    by 0x457B6CF: strdup (in /lib/libc-2.10.1.so)
>> ==12476==    by 0x7BECACC: mod_nibblebill_load (mod_nibblebill.c:128)
>>
>> ==12476== 8 bytes in 1 blocks are still reachable in loss record 28 of 141
>> ==12476==    at 0x4026378: malloc (in /usr/lib/valgrind/x86-
>> linux/vgpreload_memcheck.so)
>> ==12476==    by 0x457B6CF: strdup (in /lib/libc-2.10.1.so)
>> ==12476==    by 0x7BEC9FB: mod_nibblebill_load (mod_nibblebill.c:127)
>>
>> ==12476== 9 bytes in 1 blocks are still reachable in loss record 30 of 141
>> ==12476==    at 0x4026378: malloc (in /usr/lib/valgrind/x86-
>> linux/vgpreload_memcheck.so)
>> ==12476==    by 0x457B6CF: strdup (in /lib/libc-2.10.1.so)
>> ==12476==    by 0x7BECB19: mod_nibblebill_load (mod_nibblebill.c:129)
>>
>> ==12476== 10 bytes in 1 blocks are still reachable in loss record 34 of
>> 141
>> ==12476==    at 0x4026378: malloc (in /usr/lib/valgrind/x86-
>> linux/vgpreload_memcheck.so)
>> ==12476==    by 0x457B6CF: strdup (in /lib/libc-2.10.1.so)
>> ==12476==    by 0x7BECC8A: mod_nibblebill_load (mod_nibblebill.c:133)
>> ==12476==
>> ==12476==
>> ==12476== 10 bytes in 1 blocks are still reachable in loss record 35 of
>> 141
>> ==12476==    at 0x4026378: malloc (in /usr/lib/valgrind/x86-
>> linux/vgpreload_memcheck.so)
>> ==12476==    by 0x457B6CF: strdup (in /lib/libc-2.10.1.so)
>> ==12476==    by 0x7BEC5D6: mod_nibblebill_load (mod_nibblebill.c:125)
>>
>> ==12476== 14 bytes in 1 blocks are still reachable in loss record 45 of
>> 141
>> ==12476==    at 0x4026378: malloc (in /usr/lib/valgrind/x86-
>> linux/vgpreload_memcheck.so)
>> ==12476==    by 0x457B6CF: strdup (in /lib/libc-2.10.1.so)
>> ==12476==    by 0x7BEC54D: mod_nibblebill_load (mod_nibblebill.c:124)
>>
>> On Monday 19 April 2010, Anthony Minessale wrote:
>> > and did anything in the valgrind report even mention nibblebill?
>> > you only sent the tiny excerpt.
>> >
>> >
>> > On Mon, Apr 19, 2010 at 12:27 PM, Sergey Okhapkin
>> >
>> > <sos at sokhapkin.dyndns.org>wrote:
>> > > Anyway it's offtopic already:-) The thread was about unbounded memory
>> > > grows with enabled mod_nibblebill. On relatively busy server memory
>> stays
>> > > at about
>> > > 100M RSS for weeks if mod_nibblebill is not used, but grows to 800M in
>> > > one day
>> > > if nibbling is enabled.
>> > >
>> > > On Monday 19 April 2010, Brian West wrote:
>> > > > That still doesn't mean the dialogs were properly cleared by the sip
>> > >
>> > > stack
>> > >
>> > > >  before shutdown.  That is what anthony is getting at.  Valgrind
>> does
>> > >
>> > > make
>> > >
>> > > >  mistakes at times about what is leaking in cases like this.
>> > > >
>> > > > /b
>> > > >
>> > > > On Apr 19, 2010, at 12:06 PM, Sergey Okhapkin wrote:
>> > > > > Yes, I stopped the traffic to the server and issued hupall CLI
>> > > > > command before shutting down FS.
>> > > >
>> > > > _______________________________________________
>> > > > FreeSWITCH-users mailing list
>> > > > FreeSWITCH-users at lists.freeswitch.org
>> > > > http://lists.freeswitch.org/mailman/listinfo/freeswitch-users
>> > > > UNSUBSCRIBE:
>> http://lists.freeswitch.org/mailman/options/freeswitch-user
>> > > >s http://www.freeswitch.org
>> > >
>> > > _______________________________________________
>> > > FreeSWITCH-users mailing list
>> > > FreeSWITCH-users at lists.freeswitch.org
>> > > http://lists.freeswitch.org/mailman/listinfo/freeswitch-users
>> > > UNSUBSCRIBE:
>> http://lists.freeswitch.org/mailman/options/freeswitch-users
>> > > http://www.freeswitch.org
>> >
>>
>>
>> _______________________________________________
>> FreeSWITCH-users mailing list
>> FreeSWITCH-users at lists.freeswitch.org
>> http://lists.freeswitch.org/mailman/listinfo/freeswitch-users
>> UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users
>> http://www.freeswitch.org
>>
>
>
>
> --
> -Rupa
>



-- 
-Rupa
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.freeswitch.org/pipermail/freeswitch-users/attachments/20100419/e8d47f0a/attachment-0001.html 


More information about the FreeSWITCH-users mailing list