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

[Rupa Schomaker]

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.freeswitch.org/pipermail/freeswitch-users/attachments/20100419/38819225/attachment.html