Yes, I agree that these strdups can be ignored. I believe I found where the memory problem comes from, the beginning of bill_event function in mod_nubblebill has
SWITCH_STANDARD_STREAM(sql_stream);
But SWITCH_STANDARD_STREAM macro does malloc! I do not see a place in the function where the memory is freed. Am I right?
#define SWITCH_STANDARD_STREAM(s) memset(&s, 0, sizeof(s)); s.data = malloc(SWITCH_CMD_CHUNK_LEN); \
switch_assert(s.data); \
memset(s.data, 0, SWITCH_CMD_CHUNK_LEN); \
s.end = s.data; \
s.data_size = SWITCH_CMD_CHUNK_LEN; \
s.write_function = switch_console_stream_write; \
s.raw_write_function = switch_console_stream_raw_write; \
s.alloc_len = SWITCH_CMD_CHUNK_LEN; \
s.alloc_chunk = SWITCH_CMD_CHUNK_LEN
On Monday 19 April 2010, Rupa Schomaker 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@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@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@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@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@lists.freeswitch.org
> > http://lists.freeswitch.org/mailman/listinfo/freeswitch-users
> > UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users
> > http://www.freeswitch.org
>