Memory leak in mod_nibblebill or in ODBC core?
I want to utilize nibblebill features for prepaid support, but as soon as I enable nibble billing with set nibble_rate=XXX set nibble_account=NNNNNN set enable_heartbeat_events=60 in dialplan, FS process begins to eat more and more memory, RSS grows from 23M to 100M and more after processing few thousands calls and continues to grow. If I comment out those 3 lines from dialplan, then FS RSS grows from initial 23M to 50-60M (depending on the number of concurrent calls) and stays at this value, no memory leaks. Do anybody use mod_nibblebill? I'm experiencing this problem with all svn versions I tried including latest git version.
100M may just be the memory it is really using for what it is doing and not a leak. Have you seen anything to tell you this is actually a leak? Have you run under valgrind or some similar tool to confirm? Mike On Apr 17, 2010, at 9:26 AM, Sergey Okhapkin wrote:
I want to utilize nibblebill features for prepaid support, but as soon as I enable nibble billing with
set nibble_rate=XXX set nibble_account=NNNNNN set enable_heartbeat_events=60
in dialplan, FS process begins to eat more and more memory, RSS grows from 23M to 100M and more after processing few thousands calls and continues to grow. If I comment out those 3 lines from dialplan, then FS RSS grows from initial 23M to 50-60M (depending on the number of concurrent calls) and stays at this value, no memory leaks.
Do anybody use mod_nibblebill?
I'm experiencing this problem with all svn versions I tried including latest git version.
When memory stays at 50-60M without nibblebill and grows to 300M with... It's definetily a leak. valgring log is available, but there is nothing suspicious in it... Try to enable niblebill yourself. On Saturday 17 April 2010, Michael Jerris wrote:
100M may just be the memory it is really using for what it is doing and not a leak. Have you seen anything to tell you this is actually a leak? Have you run under valgrind or some similar tool to confirm?
Mike
On Apr 17, 2010, at 9:26 AM, Sergey Okhapkin wrote:
I want to utilize nibblebill features for prepaid support, but as soon as I enable nibble billing with
set nibble_rate=XXX set nibble_account=NNNNNN set enable_heartbeat_events=60
in dialplan, FS process begins to eat more and more memory, RSS grows from 23M to 100M and more after processing few thousands calls and continues to grow. If I comment out those 3 lines from dialplan, then FS RSS grows from initial 23M to 50-60M (depending on the number of concurrent calls) and stays at this value, no memory leaks.
Do anybody use mod_nibblebill?
I'm experiencing this problem with all svn versions I tried including latest git version.
_______________________________________________ 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
Are you using anything else that uses ODBC? You may be seeing the initial hit of ODBC. I use nibblebill (lightly) without any significant memory utilization that I can see. But then, I don't look at my memory usage so closely. 300M isn't that much... On Sat, Apr 17, 2010 at 3:34 PM, Sergey Okhapkin <sos@sokhapkin.dyndns.org>wrote:
When memory stays at 50-60M without nibblebill and grows to 300M with... It's definetily a leak. valgring log is available, but there is nothing suspicious in it... Try to enable niblebill yourself.
On Saturday 17 April 2010, Michael Jerris wrote:
100M may just be the memory it is really using for what it is doing and not a leak. Have you seen anything to tell you this is actually a leak? Have you run under valgrind or some similar tool to confirm?
Mike
On Apr 17, 2010, at 9:26 AM, Sergey Okhapkin wrote:
I want to utilize nibblebill features for prepaid support, but as soon as I enable nibble billing with
set nibble_rate=XXX set nibble_account=NNNNNN set enable_heartbeat_events=60
in dialplan, FS process begins to eat more and more memory, RSS grows from 23M to 100M and more after processing few thousands calls and continues to grow. If I comment out those 3 lines from dialplan, then FS RSS grows from initial 23M to 50-60M (depending on the number of concurrent calls) and stays at this value, no memory leaks.
Do anybody use mod_nibblebill?
I'm experiencing this problem with all svn versions I tried including latest git version.
_______________________________________________ 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
-- -Rupa
No, I do not use core ODBC. I run lua with odbc support, but to check the problem I got rid of lua and reinvited the wheel with mod_xml_curl to build the dialplan. Absolutely the same memory leak. FS takes about 60M RSS without mod_nibblebill but RSS grows up to infinity when mod_nibblebill is enabled. On Saturday 17 April 2010, Rupa Schomaker wrote:
Are you using anything else that uses ODBC? You may be seeing the initial hit of ODBC. I use nibblebill (lightly) without any significant memory utilization that I can see. But then, I don't look at my memory usage so closely. 300M isn't that much...
On Sat, Apr 17, 2010 at 3:34 PM, Sergey Okhapkin
<sos@sokhapkin.dyndns.org>wrote:
When memory stays at 50-60M without nibblebill and grows to 300M with... It's definetily a leak. valgring log is available, but there is nothing suspicious in it... Try to enable niblebill yourself.
On Saturday 17 April 2010, Michael Jerris wrote:
100M may just be the memory it is really using for what it is doing and
not
a leak. Have you seen anything to tell you this is actually a leak? Have you run under valgrind or some similar tool to confirm?
Mike
On Apr 17, 2010, at 9:26 AM, Sergey Okhapkin wrote:
I want to utilize nibblebill features for prepaid support, but as soon
as
I enable nibble billing with
set nibble_rate=XXX set nibble_account=NNNNNN set enable_heartbeat_events=60
in dialplan, FS process begins to eat more and more memory, RSS grows from 23M to 100M and more after processing few thousands calls and continues to grow. If I comment out those 3 lines from dialplan, then
FS
RSS grows from initial 23M to 50-60M (depending on the number of concurrent calls) and stays at this value, no memory leaks.
Do anybody use mod_nibblebill?
I'm experiencing this problem with all svn versions I tried including latest git version.
_______________________________________________ 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
That is a completely incorrect statement. Using memory (and caching possibly), leaking memory, and unbound growth in memory are all totally different things. to understand exactly what is going on here, the distinction is important. If you run under valgrind, you should look when its running to see where all this extra allocation is. Mike On Apr 17, 2010, at 4:34 PM, Sergey Okhapkin wrote:
When memory stays at 50-60M without nibblebill and grows to 300M with... It's definetily a leak. valgring log is available, but there is nothing suspicious in it... Try to enable niblebill yourself.
On Saturday 17 April 2010, Michael Jerris wrote:
100M may just be the memory it is really using for what it is doing and not a leak. Have you seen anything to tell you this is actually a leak? Have you run under valgrind or some similar tool to confirm?
Mike
On Apr 17, 2010, at 9:26 AM, Sergey Okhapkin wrote:
I want to utilize nibblebill features for prepaid support, but as soon as I enable nibble billing with
set nibble_rate=XXX set nibble_account=NNNNNN set enable_heartbeat_events=60
in dialplan, FS process begins to eat more and more memory, RSS grows from 23M to 100M and more after processing few thousands calls and continues to grow. If I comment out those 3 lines from dialplan, then FS RSS grows from initial 23M to 50-60M (depending on the number of concurrent calls) and stays at this value, no memory leaks.
Do anybody use mod_nibblebill?
I'm experiencing this problem with all svn versions I tried including latest git version.
_______________________________________________ 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
According to valgrind there are no big leaks. ==12476== LEAK SUMMARY: ==12476== definitely lost: 146,309 bytes in 189 blocks. ==12476== indirectly lost: 176 bytes in 12 blocks. ==12476== possibly lost: 12,336 bytes in 18 blocks. ==12476== still reachable: 1,077,431 bytes in 550 blocks. ==12476== suppressed: 0 bytes in 0 blocks. On Saturday 17 April 2010, Michael Jerris wrote:
That is a completely incorrect statement. Using memory (and caching possibly), leaking memory, and unbound growth in memory are all totally different things. to understand exactly what is going on here, the distinction is important. If you run under valgrind, you should look when its running to see where all this extra allocation is.
Mike
On Apr 17, 2010, at 4:34 PM, Sergey Okhapkin wrote:
When memory stays at 50-60M without nibblebill and grows to 300M with... It's definetily a leak. valgring log is available, but there is nothing suspicious in it... Try to enable niblebill yourself.
On Saturday 17 April 2010, Michael Jerris wrote:
100M may just be the memory it is really using for what it is doing and not a leak. Have you seen anything to tell you this is actually a leak? Have you run under valgrind or some similar tool to confirm?
Mike
On Apr 17, 2010, at 9:26 AM, Sergey Okhapkin wrote:
I want to utilize nibblebill features for prepaid support, but as soon as I enable nibble billing with
set nibble_rate=XXX set nibble_account=NNNNNN set enable_heartbeat_events=60
in dialplan, FS process begins to eat more and more memory, RSS grows from 23M to 100M and more after processing few thousands calls and continues to grow. If I comment out those 3 lines from dialplan, then FS RSS grows from initial 23M to 50-60M (depending on the number of concurrent calls) and stays at this value, no memory leaks.
Do anybody use mod_nibblebill?
I'm experiencing this problem with all svn versions I tried including latest git version.
_______________________________________________ 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
_______________________________________________ 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
That's not very useful you need a full report with extended checking. On Apr 18, 2010 7:34 AM, "Sergey Okhapkin" <sos@sokhapkin.dyndns.org> wrote: According to valgrind there are no big leaks. ==12476== LEAK SUMMARY: ==12476== definitely lost: 146,309 bytes in 189 blocks. ==12476== indirectly lost: 176 bytes in 12 blocks. ==12476== possibly lost: 12,336 bytes in 18 blocks. ==12476== still reachable: 1,077,431 bytes in 550 blocks. ==12476== suppressed: 0 bytes in 0 blocks. On Saturday 17 April 2010, Michael Jerris wrote:
That is a completely incorrect statement. Usi...
Also thatb suggests you leaked a whopping 100k On Apr 18, 2010 11:35 AM, "Anthony Minessale" <anthony.minessale@gmail.com> wrote: That's not very useful you need a full report with extended checking.
On Apr 18, 2010 7:34 AM, "Sergey Okhapkin" <sos@sokhapkin.dyndns.org>
wrote:
According to v...
On Saturday 17 April 2010, Michael Jerris wrote: That is a completely incorrect statement. Usi...
Which valgrind options should I specify? I did run valgrind --tool=memcheck --log-file=vg.log --leak-check=full --leak- resolution=high --show-reachable=yes ./freeswitch -nonat -vg 100K leaked is nothing compared to FS process RSS of 300M... On Sunday 18 April 2010, Anthony Minessale wrote:
Also thatb suggests you leaked a whopping 100k
On Apr 18, 2010 11:35 AM, "Anthony Minessale" <anthony.minessale@gmail.com> wrote:
That's not very useful you need a full report with extended checking.
On Apr 18, 2010 7:34 AM, "Sergey Okhapkin" <sos@sokhapkin.dyndns.org>
wrote:
According to v...
On Saturday 17 April 2010, Michael Jerris wrote: That is a completely incorrect statement. Usi...
300M is tiny. try having 2000 channels up you can soar into a gig of usage. That valgrind report only showed 100k leaked which means it was all accounted for and torn down in the end. If you can find a specific leak in the nibble bill module with valgrind we will gladly fix it and you can gladly thank us for giving you a way to make money by the second. valgrind --tool=memcheck --log-file=vg.log --leak-check=full --leak-resolution=high --show-reachable=yes /usr/local/freeswitch/bin/freeswitch -vg On Sun, Apr 18, 2010 at 11:48 AM, Sergey Okhapkin <sos@sokhapkin.dyndns.org>wrote:
Which valgrind options should I specify? I did run
valgrind --tool=memcheck --log-file=vg.log --leak-check=full --leak- resolution=high --show-reachable=yes ./freeswitch -nonat -vg
100K leaked is nothing compared to FS process RSS of 300M...
On Sunday 18 April 2010, Anthony Minessale wrote:
Also thatb suggests you leaked a whopping 100k
On Apr 18, 2010 11:35 AM, "Anthony Minessale" < anthony.minessale@gmail.com> wrote:
That's not very useful you need a full report with extended checking.
On Apr 18, 2010 7:34 AM, "Sergey Okhapkin" <sos@sokhapkin.dyndns.org>
wrote:
According to v...
On Saturday 17 April 2010, Michael Jerris wrote: That is a completely incorrect statement. Usi...
_______________________________________________ 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
-- Anthony Minessale II FreeSWITCH http://www.freeswitch.org/ ClueCon http://www.cluecon.com/ Twitter: http://twitter.com/FreeSWITCH_wire AIM: anthm MSN:anthony_minessale@hotmail.com <MSN%3Aanthony_minessale@hotmail.com> GTALK/JABBER/PAYPAL:anthony.minessale@gmail.com<PAYPAL%3Aanthony.minessale@gmail.com> IRC: irc.freenode.net #freeswitch FreeSWITCH Developer Conference sip:888@conference.freeswitch.org <sip%3A888@conference.freeswitch.org> googletalk:conf+888@conference.freeswitch.org<googletalk%3Aconf%2B888@conference.freeswitch.org> pstn:+19193869900
Valgrind doesn't show leaks in mod_nibblebill, most of the leaked memory was in mod_sofia: ==12476== 53,064 bytes in 67 blocks are definitely lost in loss record 138 of 141 ==12476== at 0x4026378: malloc (in /usr/lib/valgrind/x86- linux/vgpreload_memcheck.so) ==12476== by 0x6A0DC8F: sofia_handle_sip_i_invite (sofia.c:6538) ==12476== ==12476== ==12476== 92,664 bytes in 117 blocks are definitely lost in loss record 139 of 141 ==12476== at 0x4026378: malloc (in /usr/lib/valgrind/x86- linux/vgpreload_memcheck.so) ==12476== by 0x6A2F76F: sofia_glue_do_invite (sofia_glue.c:1874) ==12476== BTW, do I understand FS code correct that channel private data are always handled by sqlite, even if I enable core ODBC? On Monday 19 April 2010, Anthony Minessale wrote:
300M is tiny. try having 2000 channels up you can soar into a gig of usage.
That valgrind report only showed 100k leaked which means it was all accounted for and torn down in the end.
If you can find a specific leak in the nibble bill module with valgrind we will gladly fix it and you can gladly thank us for giving you a way to make money by the second.
valgrind --tool=memcheck --log-file=vg.log --leak-check=full --leak-resolution=high --show-reachable=yes /usr/local/freeswitch/bin/freeswitch -vg
On Sun, Apr 18, 2010 at 11:48 AM, Sergey Okhapkin
<sos@sokhapkin.dyndns.org>wrote:
Which valgrind options should I specify? I did run
valgrind --tool=memcheck --log-file=vg.log --leak-check=full --leak- resolution=high --show-reachable=yes ./freeswitch -nonat -vg
100K leaked is nothing compared to FS process RSS of 300M...
On Sunday 18 April 2010, Anthony Minessale wrote:
Also thatb suggests you leaked a whopping 100k
On Apr 18, 2010 11:35 AM, "Anthony Minessale" <
anthony.minessale@gmail.com>
wrote:
That's not very useful you need a full report with extended checking.
On Apr 18, 2010 7:34 AM, "Sergey Okhapkin" <sos@sokhapkin.dyndns.org>
wrote:
According to v...
On Saturday 17 April 2010, Michael Jerris wrote: That is a completely incorrect statement. Usi...
_______________________________________________ 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
This is invalid. Those places are where sip calls are created and they are most definitely not leaking. If anything, it suggests dialogs that are up still and not yet destroyed at the termination of the program. If this location in the code was a leak it would be gigs not megs missing. Did you do the exact command I said (especially -vg param to FS) and then a full clean shutdown all the way back to the shell? Are you maybe not getting the BYE to your calls creating open dialogs? You may want to turn on the sip trace. On Mon, Apr 19, 2010 at 10:29 AM, Sergey Okhapkin <sos@sokhapkin.dyndns.org>wrote:
Valgrind doesn't show leaks in mod_nibblebill, most of the leaked memory was in mod_sofia:
==12476== 53,064 bytes in 67 blocks are definitely lost in loss record 138 of 141 ==12476== at 0x4026378: malloc (in /usr/lib/valgrind/x86- linux/vgpreload_memcheck.so) ==12476== by 0x6A0DC8F: sofia_handle_sip_i_invite (sofia.c:6538) ==12476== ==12476== ==12476== 92,664 bytes in 117 blocks are definitely lost in loss record 139 of 141 ==12476== at 0x4026378: malloc (in /usr/lib/valgrind/x86- linux/vgpreload_memcheck.so) ==12476== by 0x6A2F76F: sofia_glue_do_invite (sofia_glue.c:1874) ==12476==
BTW, do I understand FS code correct that channel private data are always handled by sqlite, even if I enable core ODBC?
On Monday 19 April 2010, Anthony Minessale wrote:
300M is tiny. try having 2000 channels up you can soar into a gig of usage.
That valgrind report only showed 100k leaked which means it was all accounted for and torn down in the end.
If you can find a specific leak in the nibble bill module with valgrind we will gladly fix it and you can gladly thank us for giving you a way to make money by the second.
valgrind --tool=memcheck --log-file=vg.log --leak-check=full --leak-resolution=high --show-reachable=yes /usr/local/freeswitch/bin/freeswitch -vg
On Sun, Apr 18, 2010 at 11:48 AM, Sergey Okhapkin
<sos@sokhapkin.dyndns.org>wrote:
Which valgrind options should I specify? I did run
valgrind --tool=memcheck --log-file=vg.log --leak-check=full --leak- resolution=high --show-reachable=yes ./freeswitch -nonat -vg
100K leaked is nothing compared to FS process RSS of 300M...
On Sunday 18 April 2010, Anthony Minessale wrote:
Also thatb suggests you leaked a whopping 100k
On Apr 18, 2010 11:35 AM, "Anthony Minessale" <
anthony.minessale@gmail.com>
wrote:
That's not very useful you need a full report with extended checking.
On Apr 18, 2010 7:34 AM, "Sergey Okhapkin" < sos@sokhapkin.dyndns.org>
wrote:
According to v...
On Saturday 17 April 2010, Michael Jerris wrote: That is a completely incorrect statement. Usi...
_______________________________________________ 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
-- Anthony Minessale II FreeSWITCH http://www.freeswitch.org/ ClueCon http://www.cluecon.com/ Twitter: http://twitter.com/FreeSWITCH_wire AIM: anthm MSN:anthony_minessale@hotmail.com <MSN%3Aanthony_minessale@hotmail.com> GTALK/JABBER/PAYPAL:anthony.minessale@gmail.com<PAYPAL%3Aanthony.minessale@gmail.com> IRC: irc.freenode.net #freeswitch FreeSWITCH Developer Conference sip:888@conference.freeswitch.org <sip%3A888@conference.freeswitch.org> googletalk:conf+888@conference.freeswitch.org<googletalk%3Aconf%2B888@conference.freeswitch.org> pstn:+19193869900
The command was exactly as you suggested, FS was started with "-nonat -vg" command line options, after few hours run (about 5K calls processed) FS was shut down gracefully. On Monday 19 April 2010, Anthony Minessale wrote:
This is invalid.
Those places are where sip calls are created and they are most definitely not leaking. If anything, it suggests dialogs that are up still and not yet destroyed at the termination of the program. If this location in the code was a leak it would be gigs not megs missing.
Did you do the exact command I said (especially -vg param to FS) and then a full clean shutdown all the way back to the shell?
Are you maybe not getting the BYE to your calls creating open dialogs? You may want to turn on the sip trace.
On Mon, Apr 19, 2010 at 10:29 AM, Sergey Okhapkin
<sos@sokhapkin.dyndns.org>wrote:
Valgrind doesn't show leaks in mod_nibblebill, most of the leaked memory was in mod_sofia:
==12476== 53,064 bytes in 67 blocks are definitely lost in loss record 138 of 141 ==12476== at 0x4026378: malloc (in /usr/lib/valgrind/x86- linux/vgpreload_memcheck.so) ==12476== by 0x6A0DC8F: sofia_handle_sip_i_invite (sofia.c:6538) ==12476== ==12476== ==12476== 92,664 bytes in 117 blocks are definitely lost in loss record 139 of 141 ==12476== at 0x4026378: malloc (in /usr/lib/valgrind/x86- linux/vgpreload_memcheck.so) ==12476== by 0x6A2F76F: sofia_glue_do_invite (sofia_glue.c:1874) ==12476==
BTW, do I understand FS code correct that channel private data are always handled by sqlite, even if I enable core ODBC?
On Monday 19 April 2010, Anthony Minessale wrote:
300M is tiny. try having 2000 channels up you can soar into a gig of
usage.
That valgrind report only showed 100k leaked which means it was all accounted for and torn down in the end.
If you can find a specific leak in the nibble bill module with valgrind
we
will gladly fix it and you can gladly thank us for giving you a way to make money by the second.
valgrind --tool=memcheck --log-file=vg.log --leak-check=full --leak-resolution=high --show-reachable=yes /usr/local/freeswitch/bin/freeswitch -vg
On Sun, Apr 18, 2010 at 11:48 AM, Sergey Okhapkin
<sos@sokhapkin.dyndns.org>wrote:
Which valgrind options should I specify? I did run
valgrind --tool=memcheck --log-file=vg.log --leak-check=full --leak- resolution=high --show-reachable=yes ./freeswitch -nonat -vg
100K leaked is nothing compared to FS process RSS of 300M...
On Sunday 18 April 2010, Anthony Minessale wrote:
Also thatb suggests you leaked a whopping 100k
On Apr 18, 2010 11:35 AM, "Anthony Minessale" <
anthony.minessale@gmail.com>
wrote:
That's not very useful you need a full report with extended checking.
On Apr 18, 2010 7:34 AM, "Sergey Okhapkin" <
sos@sokhapkin.dyndns.org>
wrote:
According to v...
On Saturday 17 April 2010, Michael Jerris wrote: That is a completely incorrect statement. Usi...
_______________________________________________ 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
_______________________________________________ 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
welll you are losing sip dialogs somewhere. It's not a leak its loss of sip dialogs most likely a side effect of topology problems. On Mon, Apr 19, 2010 at 11:03 AM, Sergey Okhapkin <sos@sokhapkin.dyndns.org>wrote:
The command was exactly as you suggested, FS was started with "-nonat -vg" command line options, after few hours run (about 5K calls processed) FS was shut down gracefully.
On Monday 19 April 2010, Anthony Minessale wrote:
This is invalid.
Those places are where sip calls are created and they are most definitely not leaking. If anything, it suggests dialogs that are up still and not yet destroyed at the termination of the program. If this location in the code was a leak it would be gigs not megs missing.
Did you do the exact command I said (especially -vg param to FS) and then a full clean shutdown all the way back to the shell?
Are you maybe not getting the BYE to your calls creating open dialogs? You may want to turn on the sip trace.
On Mon, Apr 19, 2010 at 10:29 AM, Sergey Okhapkin
<sos@sokhapkin.dyndns.org>wrote:
Valgrind doesn't show leaks in mod_nibblebill, most of the leaked memory was in mod_sofia:
==12476== 53,064 bytes in 67 blocks are definitely lost in loss record 138 of 141 ==12476== at 0x4026378: malloc (in /usr/lib/valgrind/x86- linux/vgpreload_memcheck.so) ==12476== by 0x6A0DC8F: sofia_handle_sip_i_invite (sofia.c:6538) ==12476== ==12476== ==12476== 92,664 bytes in 117 blocks are definitely lost in loss record 139 of 141 ==12476== at 0x4026378: malloc (in /usr/lib/valgrind/x86- linux/vgpreload_memcheck.so) ==12476== by 0x6A2F76F: sofia_glue_do_invite (sofia_glue.c:1874) ==12476==
BTW, do I understand FS code correct that channel private data are always handled by sqlite, even if I enable core ODBC?
On Monday 19 April 2010, Anthony Minessale wrote:
300M is tiny. try having 2000 channels up you can soar into a gig of
usage.
That valgrind report only showed 100k leaked which means it was all accounted for and torn down in the end.
If you can find a specific leak in the nibble bill module with valgrind
we
will gladly fix it and you can gladly thank us for giving you a way to make money by the second.
valgrind --tool=memcheck --log-file=vg.log --leak-check=full --leak-resolution=high --show-reachable=yes /usr/local/freeswitch/bin/freeswitch -vg
On Sun, Apr 18, 2010 at 11:48 AM, Sergey Okhapkin
<sos@sokhapkin.dyndns.org>wrote:
Which valgrind options should I specify? I did run
valgrind --tool=memcheck --log-file=vg.log --leak-check=full --leak- resolution=high --show-reachable=yes ./freeswitch -nonat -vg
100K leaked is nothing compared to FS process RSS of 300M...
On Sunday 18 April 2010, Anthony Minessale wrote:
Also thatb suggests you leaked a whopping 100k
On Apr 18, 2010 11:35 AM, "Anthony Minessale" <
anthony.minessale@gmail.com>
wrote:
That's not very useful you need a full report with extended checking.
> On Apr 18, 2010 7:34 AM, "Sergey Okhapkin" <
sos@sokhapkin.dyndns.org>
wrote: > According to v... > > > > > > On Saturday 17 April 2010, Michael Jerris wrote: > That is a completely incorrect statement. Usi...
_______________________________________________ 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
_______________________________________________ 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
-- Anthony Minessale II FreeSWITCH http://www.freeswitch.org/ ClueCon http://www.cluecon.com/ Twitter: http://twitter.com/FreeSWITCH_wire AIM: anthm MSN:anthony_minessale@hotmail.com <MSN%3Aanthony_minessale@hotmail.com> GTALK/JABBER/PAYPAL:anthony.minessale@gmail.com<PAYPAL%3Aanthony.minessale@gmail.com> IRC: irc.freenode.net #freeswitch FreeSWITCH Developer Conference sip:888@conference.freeswitch.org <sip%3A888@conference.freeswitch.org> googletalk:conf+888@conference.freeswitch.org<googletalk%3Aconf%2B888@conference.freeswitch.org> pstn:+19193869900
It's possible that some BYE or ACK could be lost, but shouldn't sip dialogs be destroyed automatically after a timeout? On Monday 19 April 2010, Anthony Minessale wrote:
welll you are losing sip dialogs somewhere. It's not a leak its loss of sip dialogs most likely a side effect of topology problems.
On Mon, Apr 19, 2010 at 11:03 AM, Sergey Okhapkin
<sos@sokhapkin.dyndns.org>wrote:
The command was exactly as you suggested, FS was started with "-nonat -vg" command line options, after few hours run (about 5K calls processed) FS was shut down gracefully.
On Monday 19 April 2010, Anthony Minessale wrote:
This is invalid.
Those places are where sip calls are created and they are most definitely not leaking. If anything, it suggests dialogs that are up still and not yet destroyed
at
the termination of the program. If this location in the code was a leak it would be gigs not megs
missing.
Did you do the exact command I said (especially -vg param to FS) and then
a
full clean shutdown all the way back to the shell?
Are you maybe not getting the BYE to your calls creating open dialogs? You may want to turn on the sip trace.
On Mon, Apr 19, 2010 at 10:29 AM, Sergey Okhapkin
<sos@sokhapkin.dyndns.org>wrote:
Valgrind doesn't show leaks in mod_nibblebill, most of the leaked
memory
was in mod_sofia:
==12476== 53,064 bytes in 67 blocks are definitely lost in loss record 138 of 141 ==12476== at 0x4026378: malloc (in /usr/lib/valgrind/x86- linux/vgpreload_memcheck.so) ==12476== by 0x6A0DC8F: sofia_handle_sip_i_invite (sofia.c:6538) ==12476== ==12476== ==12476== 92,664 bytes in 117 blocks are definitely lost in loss record 139 of 141 ==12476== at 0x4026378: malloc (in /usr/lib/valgrind/x86- linux/vgpreload_memcheck.so) ==12476== by 0x6A2F76F: sofia_glue_do_invite (sofia_glue.c:1874) ==12476==
BTW, do I understand FS code correct that channel private data are
always
handled by sqlite, even if I enable core ODBC?
On Monday 19 April 2010, Anthony Minessale wrote:
300M is tiny. try having 2000 channels up you can soar into a gig of
usage.
That valgrind report only showed 100k leaked which means it was all accounted for and torn down in the end.
If you can find a specific leak in the nibble bill module with
valgrind
we
will gladly fix it and you can gladly thank us for giving you a way to make money by the second.
valgrind --tool=memcheck --log-file=vg.log --leak-check=full --leak-resolution=high --show-reachable=yes /usr/local/freeswitch/bin/freeswitch -vg
On Sun, Apr 18, 2010 at 11:48 AM, Sergey Okhapkin
<sos@sokhapkin.dyndns.org>wrote:
Which valgrind options should I specify? I did run
valgrind --tool=memcheck --log-file=vg.log --leak-check=full
--leak-
resolution=high --show-reachable=yes ./freeswitch -nonat -vg
100K leaked is nothing compared to FS process RSS of 300M...
On Sunday 18 April 2010, Anthony Minessale wrote: > Also thatb suggests you leaked a whopping 100k > > On Apr 18, 2010 11:35 AM, "Anthony Minessale" <
anthony.minessale@gmail.com>
> wrote: > > That's not very useful you need a full report with extended > checking. > > > On Apr 18, 2010 7:34 AM, "Sergey Okhapkin" <
sos@sokhapkin.dyndns.org>
> wrote: > > According to v... > > > > > > > > > > > > On Saturday 17 April 2010, Michael Jerris wrote: > > That is a completely incorrect statement. Usi...
_______________________________________________ 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
_______________________________________________ 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
_______________________________________________ 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
yes its a function of the sofia-sip project, but did you wait before you stopped it? We have people sending non stop 200+calls a second complaining about no leaks. So if you have some real problem it's going to be your network conditions and interop with your providers causing an edge case with the SIP stack itself who has it's own list and irc channel. On Mon, Apr 19, 2010 at 11:45 AM, Sergey Okhapkin <sos@sokhapkin.dyndns.org>wrote:
It's possible that some BYE or ACK could be lost, but shouldn't sip dialogs be destroyed automatically after a timeout?
On Monday 19 April 2010, Anthony Minessale wrote:
welll you are losing sip dialogs somewhere. It's not a leak its loss of sip dialogs most likely a side effect of topology problems.
On Mon, Apr 19, 2010 at 11:03 AM, Sergey Okhapkin
<sos@sokhapkin.dyndns.org>wrote:
The command was exactly as you suggested, FS was started with "-nonat -vg" command line options, after few hours run (about 5K calls processed) FS was shut down gracefully.
On Monday 19 April 2010, Anthony Minessale wrote:
This is invalid.
Those places are where sip calls are created and they are most definitely not leaking. If anything, it suggests dialogs that are up still and not yet destroyed
at
the termination of the program. If this location in the code was a leak it would be gigs not megs
missing.
Did you do the exact command I said (especially -vg param to FS) and then
a
full clean shutdown all the way back to the shell?
Are you maybe not getting the BYE to your calls creating open dialogs? You may want to turn on the sip trace.
On Mon, Apr 19, 2010 at 10:29 AM, Sergey Okhapkin
<sos@sokhapkin.dyndns.org>wrote:
Valgrind doesn't show leaks in mod_nibblebill, most of the leaked
memory
was in mod_sofia:
==12476== 53,064 bytes in 67 blocks are definitely lost in loss record 138 of 141 ==12476== at 0x4026378: malloc (in /usr/lib/valgrind/x86- linux/vgpreload_memcheck.so) ==12476== by 0x6A0DC8F: sofia_handle_sip_i_invite (sofia.c:6538) ==12476== ==12476== ==12476== 92,664 bytes in 117 blocks are definitely lost in loss record 139 of 141 ==12476== at 0x4026378: malloc (in /usr/lib/valgrind/x86- linux/vgpreload_memcheck.so) ==12476== by 0x6A2F76F: sofia_glue_do_invite (sofia_glue.c:1874) ==12476==
BTW, do I understand FS code correct that channel private data are
always
handled by sqlite, even if I enable core ODBC?
On Monday 19 April 2010, Anthony Minessale wrote:
300M is tiny. try having 2000 channels up you can soar into a gig of
usage.
That valgrind report only showed 100k leaked which means it was all accounted for and torn down in the end.
If you can find a specific leak in the nibble bill module with
valgrind
we
will gladly fix it and you can gladly thank us for giving you a way to make money by the second.
valgrind --tool=memcheck --log-file=vg.log --leak-check=full --leak-resolution=high --show-reachable=yes /usr/local/freeswitch/bin/freeswitch -vg
On Sun, Apr 18, 2010 at 11:48 AM, Sergey Okhapkin
<sos@sokhapkin.dyndns.org>wrote: > Which valgrind options should I specify? I did run > > valgrind --tool=memcheck --log-file=vg.log --leak-check=full
--leak-
> resolution=high --show-reachable=yes ./freeswitch -nonat -vg > > 100K leaked is nothing compared to FS process RSS of 300M... > > On Sunday 18 April 2010, Anthony Minessale wrote: > > Also thatb suggests you leaked a whopping 100k > > > > On Apr 18, 2010 11:35 AM, "Anthony Minessale" < > > anthony.minessale@gmail.com> > > > wrote: > > > > That's not very useful you need a full report with extended > > checking. > > > > > On Apr 18, 2010 7:34 AM, "Sergey Okhapkin" <
sos@sokhapkin.dyndns.org>
> > wrote: > > > According to v... > > > > > > > > > > > > > > > > > > On Saturday 17 April 2010, Michael Jerris wrote: > > > That is a completely incorrect statement. Usi... > > _______________________________________________ > 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
_______________________________________________ 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
_______________________________________________ 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
-- Anthony Minessale II FreeSWITCH http://www.freeswitch.org/ ClueCon http://www.cluecon.com/ Twitter: http://twitter.com/FreeSWITCH_wire AIM: anthm MSN:anthony_minessale@hotmail.com <MSN%3Aanthony_minessale@hotmail.com> GTALK/JABBER/PAYPAL:anthony.minessale@gmail.com<PAYPAL%3Aanthony.minessale@gmail.com> IRC: irc.freenode.net #freeswitch FreeSWITCH Developer Conference sip:888@conference.freeswitch.org <sip%3A888@conference.freeswitch.org> googletalk:conf+888@conference.freeswitch.org<googletalk%3Aconf%2B888@conference.freeswitch.org> pstn:+19193869900
Yes, I stopped the traffic to the server and issued hupall CLI command before shutting down FS. On Monday 19 April 2010, Anthony Minessale wrote:
yes its a function of the sofia-sip project, but did you wait before you stopped it? We have people sending non stop 200+calls a second complaining about no leaks. So if you have some real problem it's going to be your network conditions and interop with your providers causing an edge case with the SIP stack itself who has it's own list and irc channel.
On Mon, Apr 19, 2010 at 11:45 AM, Sergey Okhapkin
<sos@sokhapkin.dyndns.org>wrote:
It's possible that some BYE or ACK could be lost, but shouldn't sip dialogs be destroyed automatically after a timeout?
On Monday 19 April 2010, Anthony Minessale wrote:
welll you are losing sip dialogs somewhere. It's not a leak its loss of sip dialogs most likely a side effect of topology problems.
On Mon, Apr 19, 2010 at 11:03 AM, Sergey Okhapkin
<sos@sokhapkin.dyndns.org>wrote:
The command was exactly as you suggested, FS was started with "-nonat -vg" command line options, after few hours run (about 5K calls
processed)
FS was shut down gracefully.
On Monday 19 April 2010, Anthony Minessale wrote:
This is invalid.
Those places are where sip calls are created and they are most definitely not leaking. If anything, it suggests dialogs that are up still and not yet destroyed
at
the termination of the program. If this location in the code was a leak it would be gigs not megs
missing.
Did you do the exact command I said (especially -vg param to FS) and then
a
full clean shutdown all the way back to the shell?
Are you maybe not getting the BYE to your calls creating open
dialogs?
You may want to turn on the sip trace.
On Mon, Apr 19, 2010 at 10:29 AM, Sergey Okhapkin
<sos@sokhapkin.dyndns.org>wrote:
Valgrind doesn't show leaks in mod_nibblebill, most of the leaked
memory
was in mod_sofia:
==12476== 53,064 bytes in 67 blocks are definitely lost in loss record 138 of 141 ==12476== at 0x4026378: malloc (in /usr/lib/valgrind/x86- linux/vgpreload_memcheck.so) ==12476== by 0x6A0DC8F: sofia_handle_sip_i_invite (sofia.c:6538) ==12476== ==12476== ==12476== 92,664 bytes in 117 blocks are definitely lost in loss record 139 of 141 ==12476== at 0x4026378: malloc (in /usr/lib/valgrind/x86- linux/vgpreload_memcheck.so) ==12476== by 0x6A2F76F: sofia_glue_do_invite (sofia_glue.c:1874) ==12476==
BTW, do I understand FS code correct that channel private data are
always
handled by sqlite, even if I enable core ODBC?
On Monday 19 April 2010, Anthony Minessale wrote: > 300M is tiny. try having 2000 channels up you can soar into a > gig of
usage.
> That valgrind report only showed 100k leaked which means it was
all
> accounted for and torn down in the end. > > If you can find a specific leak in the nibble bill module with
valgrind
we
> will gladly fix it and you > can gladly thank us for giving you a way to make money by the > second. > > valgrind --tool=memcheck --log-file=vg.log --leak-check=full > --leak-resolution=high --show-reachable=yes > /usr/local/freeswitch/bin/freeswitch -vg > > > > On Sun, Apr 18, 2010 at 11:48 AM, Sergey Okhapkin > > <sos@sokhapkin.dyndns.org>wrote: > > Which valgrind options should I specify? I did run > > > > valgrind --tool=memcheck --log-file=vg.log --leak-check=full
--leak-
> > resolution=high --show-reachable=yes ./freeswitch -nonat -vg > > > > 100K leaked is nothing compared to FS process RSS of 300M... > > > > On Sunday 18 April 2010, Anthony Minessale wrote: > > > Also thatb suggests you leaked a whopping 100k > > > > > > On Apr 18, 2010 11:35 AM, "Anthony Minessale" < > > > > anthony.minessale@gmail.com> > > > > > wrote: > > > > > > That's not very useful you need a full report with extended > > > checking. > > > > > > > On Apr 18, 2010 7:34 AM, "Sergey Okhapkin" <
sos@sokhapkin.dyndns.org>
> > > wrote: > > > > According to v... > > > > > > > > > > > > > > > > > > > > > > > > On Saturday 17 April 2010, Michael Jerris wrote: > > > > That is a completely incorrect statement. Usi... > > > > _______________________________________________ > > 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
_______________________________________________ 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
_______________________________________________ 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
_______________________________________________ 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
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.
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-users http://www.freeswitch.org
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-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
-- Anthony Minessale II FreeSWITCH http://www.freeswitch.org/ ClueCon http://www.cluecon.com/ Twitter: http://twitter.com/FreeSWITCH_wire AIM: anthm MSN:anthony_minessale@hotmail.com <MSN%3Aanthony_minessale@hotmail.com> GTALK/JABBER/PAYPAL:anthony.minessale@gmail.com<PAYPAL%3Aanthony.minessale@gmail.com> IRC: irc.freenode.net #freeswitch FreeSWITCH Developer Conference sip:888@conference.freeswitch.org <sip%3A888@conference.freeswitch.org> googletalk:conf+888@conference.freeswitch.org<googletalk%3Aconf%2B888@conference.freeswitch.org> pstn:+19193869900
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
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
-- -Rupa
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@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@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
-- -Rupa
-- -Rupa
The question is why aren't they on the module pool? Sounds like to me its not a leak but pool swell. Someone is duping off the wrong pool. Should use session pool if its session related data. Sounds like maybe something is using the wrong pool. /b On Apr 19, 2010, at 1:12 PM, 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.
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
_______________________________________________ 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
_______________________________________________ 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
stream.data must be freed, in that case i think its being converted to char by assigning sql to point at it but it is still freed in the end, that type of mistake would be all over the place in valgrind. look for a pool that is being reused over and over and never destroyed. On Mon, Apr 19, 2010 at 1:25 PM, Sergey Okhapkin <sos@sokhapkin.dyndns.org>wrote:
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:
_______________________________________________
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
_______________________________________________
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
_______________________________________________ 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
-- Anthony Minessale II FreeSWITCH http://www.freeswitch.org/ ClueCon http://www.cluecon.com/ Twitter: http://twitter.com/FreeSWITCH_wire AIM: anthm MSN:anthony_minessale@hotmail.com <MSN%3Aanthony_minessale@hotmail.com> GTALK/JABBER/PAYPAL:anthony.minessale@gmail.com<PAYPAL%3Aanthony.minessale@gmail.com> IRC: irc.freenode.net #freeswitch FreeSWITCH Developer Conference sip:888@conference.freeswitch.org <sip%3A888@conference.freeswitch.org> googletalk:conf+888@conference.freeswitch.org<googletalk%3Aconf%2B888@conference.freeswitch.org> pstn:+19193869900
No this isn't the problem it would show up on valgrind like crazy. /b On Apr 19, 2010, at 1:25 PM, Sergey Okhapkin wrote:
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
It would be the problem if custom_sql_* is set in nibblebill configuration, but it's not my case, I do not use custom sql. I'm looking at the code more.... On Monday 19 April 2010, Brian West wrote:
No this isn't the problem it would show up on valgrind like crazy.
/b
On Apr 19, 2010, at 1:25 PM, Sergey Okhapkin wrote:
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
We have many sets of eyes looking at this code also. What distro are you on? what compiler are you using? /b On Apr 19, 2010, at 2:17 PM, Sergey Okhapkin wrote:
It would be the problem if custom_sql_* is set in nibblebill configuration, but it's not my case, I do not use custom sql. I'm looking at the code more....
On Monday 19 April 2010, Brian West wrote:
No this isn't the problem it would show up on valgrind like crazy.
/b
gentoo, gcc version 4.3.4 (Gentoo 4.3.4 p1.0, pie-10.1.5) On Monday 19 April 2010, Brian West wrote:
We have many sets of eyes looking at this code also. What distro are you on? what compiler are you using?
/b
On Apr 19, 2010, at 2:17 PM, Sergey Okhapkin wrote:
It would be the problem if custom_sql_* is set in nibblebill configuration, but it's not my case, I do not use custom sql. I'm looking at the code more....
On Monday 19 April 2010, Brian West wrote:
No this isn't the problem it would show up on valgrind like crazy.
/b
_______________________________________________ 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
Can you try to reproduce this on centos? I have seen too many issues specific to Gentoo over the years that I would like to eliminate it from the start. Mike On Apr 19, 2010, at 3:32 PM, Sergey Okhapkin wrote:
gentoo, gcc version 4.3.4 (Gentoo 4.3.4 p1.0, pie-10.1.5)
On Monday 19 April 2010, Brian West wrote:
We have many sets of eyes looking at this code also. What distro are you on? what compiler are you using?
/b
On Apr 19, 2010, at 2:17 PM, Sergey Okhapkin wrote:
It would be the problem if custom_sql_* is set in nibblebill configuration, but it's not my case, I do not use custom sql. I'm looking at the code more....
On Monday 19 April 2010, Brian West wrote:
No this isn't the problem it would show up on valgrind like crazy.
/b
No, I do not have centos servers, gentoo only... But looks like I'm not the only unlucky: http://www.mail-archive.com/freeswitch- users@lists.freeswitch.org/msg18567.html On Monday 19 April 2010, Michael Jerris wrote:
Can you try to reproduce this on centos? I have seen too many issues specific to Gentoo over the years that I would like to eliminate it from the start.
Mike
On Apr 19, 2010, at 3:32 PM, Sergey Okhapkin wrote:
gentoo, gcc version 4.3.4 (Gentoo 4.3.4 p1.0, pie-10.1.5)
On Monday 19 April 2010, Brian West wrote:
We have many sets of eyes looking at this code also. What distro are you on? what compiler are you using?
/b
On Apr 19, 2010, at 2:17 PM, Sergey Okhapkin wrote:
It would be the problem if custom_sql_* is set in nibblebill configuration, but it's not my case, I do not use custom sql. I'm looking at the code more....
On Monday 19 April 2010, Brian West wrote:
No this isn't the problem it would show up on valgrind like crazy.
/b
_______________________________________________ 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
It only takes a few moments to go on over to www.centos.org and create one. ./b On Apr 19, 2010, at 3:34 PM, Sergey Okhapkin wrote:
No, I do not have centos servers, gentoo only...
But looks like I'm not the only unlucky:
http://www.mail-archive.com/freeswitch- users@lists.freeswitch.org/msg18567.html
On Monday 19 April 2010, Michael Jerris wrote:
Can you try to reproduce this on centos? I have seen too many issues specific to Gentoo over the years that I would like to eliminate it from the start.
Mike
ok, custom_sql path is fixed as of: [master 9a74958] nibblebill - free properly if using custom_sql On Mon, Apr 19, 2010 at 2:17 PM, Sergey Okhapkin <sos@sokhapkin.dyndns.org>wrote:
It would be the problem if custom_sql_* is set in nibblebill configuration, but it's not my case, I do not use custom sql. I'm looking at the code more....
On Monday 19 April 2010, Brian West wrote:
No this isn't the problem it would show up on valgrind like crazy.
/b
On Apr 19, 2010, at 1:25 PM, Sergey Okhapkin wrote:
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
_______________________________________________ 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
-- -Rupa
Looks like I found a work around. I set <param name="global_heartbeat" value="off"/> in nibblebill.conf.xml and execute "nibblebill heartbeat 60" in dialplan. No more unbounded memory growth. As soon as I set global_heartbeat, memory starts grow again. Go figure... On Monday 19 April 2010, Sergey Okhapkin wrote:
It would be the problem if custom_sql_* is set in nibblebill configuration, but it's not my case, I do not use custom sql. I'm looking at the code more....
On Monday 19 April 2010, Brian West wrote:
No this isn't the problem it would show up on valgrind like crazy.
/b
On Apr 19, 2010, at 1:25 PM, Sergey Okhapkin wrote:
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
_______________________________________________ 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
Sergey: Which version of nibbliebill are you using. We are having memory leak issue as well with freeswitch 1.0.4 , but I haven't try to disable nibblebill in our test, I will do that now. But since we are already doing what you say about "<param name="global_heartbeat" value="off"/> in nibblebill.conf.xml and execute "nibblebill heartbeat 60" in dialplan." in our current environment, and still getting memory leak, I am wondering if you are using nibblebill that comes with the freeswitch 1.0.6 version. Thanks, On Mon, May 10, 2010 at 1:12 AM, Sergey Okhapkin <sos@sokhapkin.dyndns.org>wrote:
Looks like I found a work around. I set <param name="global_heartbeat" value="off"/> in nibblebill.conf.xml and execute "nibblebill heartbeat 60" in dialplan. No more unbounded memory growth. As soon as I set global_heartbeat, memory starts grow again. Go figure...
On Monday 19 April 2010, Sergey Okhapkin wrote:
It would be the problem if custom_sql_* is set in nibblebill configuration, but it's not my case, I do not use custom sql. I'm looking at the code more....
On Monday 19 April 2010, Brian West wrote:
No this isn't the problem it would show up on valgrind like crazy.
/b
On Apr 19, 2010, at 1:25 PM, Sergey Okhapkin wrote:
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
_______________________________________________ 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
-- Henry Huang VoIP & Open Source software Consultant
I run git trunk. I afraid the workaround doesn't work, memory usage still grows, but slower than with global_heartbeat set. On Sunday 09 May 2010, Henry Huang wrote:
Sergey:
Which version of nibbliebill are you using. We are having memory leak issue as well with freeswitch 1.0.4 , but I haven't try to disable nibblebill in our test, I will do that now. But since we are already doing what you say about "<param name="global_heartbeat" value="off"/> in nibblebill.conf.xml and execute "nibblebill heartbeat 60" in dialplan." in our current environment, and still getting memory leak, I am wondering if you are using nibblebill that comes with the freeswitch 1.0.6 version.
Thanks,
On Mon, May 10, 2010 at 1:12 AM, Sergey Okhapkin
<sos@sokhapkin.dyndns.org>wrote:
Looks like I found a work around. I set <param name="global_heartbeat" value="off"/> in nibblebill.conf.xml and execute "nibblebill heartbeat 60" in dialplan. No more unbounded memory growth. As soon as I set global_heartbeat, memory starts grow again. Go figure...
On Monday 19 April 2010, Sergey Okhapkin wrote:
It would be the problem if custom_sql_* is set in nibblebill
configuration,
but it's not my case, I do not use custom sql. I'm looking at the code more....
On Monday 19 April 2010, Brian West wrote:
No this isn't the problem it would show up on valgrind like crazy.
/b
On Apr 19, 2010, at 1:25 PM, Sergey Okhapkin wrote:
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
_______________________________________________ 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
Please use valgrind and see where its leaking then open a jira. Nobody has been able to reproduce this in a lab nor provide any details to assist in finding the issue... All I have seen is people complaining about it and not doing what they should debugging the issue and reporting it. /b On May 9, 2010, at 1:11 PM, Sergey Okhapkin wrote:
I run git trunk. I afraid the workaround doesn't work, memory usage still grows, but slower than with global_heartbeat set.
Valgrind output shows no significant leaks. This was discussed already in this thread a month ago. On Sunday 09 May 2010, Brian West wrote:
Please use valgrind and see where its leaking then open a jira.
Nobody has been able to reproduce this in a lab nor provide any details to assist in finding the issue... All I have seen is people complaining about it and not doing what they should debugging the issue and reporting it.
/b
On May 9, 2010, at 1:11 PM, Sergey Okhapkin wrote:
I run git trunk. I afraid the workaround doesn't work, memory usage still grows, but slower than with global_heartbeat set.
_______________________________________________ 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
What are you calling significant memory usage? /b On May 9, 2010, at 2:10 PM, Sergey Okhapkin wrote:
Valgrind output shows no significant leaks. This was discussed already in this thread a month ago.
On Sunday 09 May 2010, Brian West wrote:
Please use valgrind and see where its leaking then open a jira.
Nobody has been able to reproduce this in a lab nor provide any details to assist in finding the issue... All I have seen is people complaining about it and not doing what they should debugging the issue and reporting it.
/b
RSS grows to 300M on 100 concurrent calls during several hours. With mod_nibblebill disabled RSS stays at about 60-70M On Sunday 09 May 2010, Brian West wrote:
What are you calling significant memory usage?
/b
On May 9, 2010, at 2:10 PM, Sergey Okhapkin wrote:
Valgrind output shows no significant leaks. This was discussed already in this thread a month ago.
On Sunday 09 May 2010, Brian West wrote:
Please use valgrind and see where its leaking then open a jira.
Nobody has been able to reproduce this in a lab nor provide any details to assist in finding the issue... All I have seen is people complaining about it and not doing what they should debugging the issue and reporting it.
/b
_______________________________________________ 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
Shouldn't label "end:" be BEFORE switch_odbc_statement_handle_free(&stmt); ? I think it should... static switch_status_t bill_event( .... if (switch_odbc_handle_exec(globals.master_odbc, sql, &stmt, NULL) != SWITCH_ODBC_SUCCESS) { char *err_str; err_str = switch_odbc_handle_get_error(globals.master_odbc, stmt); switch_log_printf(SWITCH_CHANNEL_LOG, SWITCH_LOG_ERROR, "ERR: [%s]\n[%s]\n", sql, switch_str_nil(err_str)); switch_safe_free(err_str); } else { /* TODO: Failover to a flat/text file if DB is unavailable */ goto end; } switch_odbc_statement_handle_free(&stmt); end: On Sunday 09 May 2010, Brian West wrote:
What are you calling significant memory usage?
/b
On May 9, 2010, at 2:10 PM, Sergey Okhapkin wrote:
Valgrind output shows no significant leaks. This was discussed already in this thread a month ago.
On Sunday 09 May 2010, Brian West wrote:
Please use valgrind and see where its leaking then open a jira.
Nobody has been able to reproduce this in a lab nor provide any details to assist in finding the issue... All I have seen is people complaining about it and not doing what they should debugging the issue and reporting it.
/b
_______________________________________________ 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
Why does this thread continue on the list instead of being opened in JIRA Can you see how this issue can be forgotten because it's on the mailing list that gets 200 emails a day? When you show the code in the body of an email like that, then I have to spend a minuted wondering where in the code you were talking about because it's not in the form of a unified diff. I appreciate that you do not normally have to deal with organized software management but I must ask that you please spend a little time to learn our customs and use JIRA and patches to communicate bug reports. I am glad you are helping to find problems but we really need to stay organized to make it forward. I redid the function in latest GIT. It did look like it was doing a few things wrong but they probably would have surfaced in valgrind if you were running it in full leak check mode. When you say it goes to 300M, does it keep going from there because there is a bit of memory that will be pooled as you start to use more advanced features. Did you ever watch it to see how high it will go? On Sun, May 9, 2010 at 4:01 PM, Sergey Okhapkin <sos@sokhapkin.dyndns.org>wrote:
Shouldn't label "end:" be BEFORE switch_odbc_statement_handle_free(&stmt); ? I think it should...
static switch_status_t bill_event( ....
if (switch_odbc_handle_exec(globals.master_odbc, sql, &stmt, NULL) != SWITCH_ODBC_SUCCESS) { char *err_str; err_str = switch_odbc_handle_get_error(globals.master_odbc, stmt); switch_log_printf(SWITCH_CHANNEL_LOG, SWITCH_LOG_ERROR, "ERR: [%s]\n[%s]\n", sql, switch_str_nil(err_str)); switch_safe_free(err_str); } else { /* TODO: Failover to a flat/text file if DB is unavailable */
goto end; }
switch_odbc_statement_handle_free(&stmt);
end:
On Sunday 09 May 2010, Brian West wrote:
What are you calling significant memory usage?
/b
On May 9, 2010, at 2:10 PM, Sergey Okhapkin wrote:
Valgrind output shows no significant leaks. This was discussed already in this thread a month ago.
On Sunday 09 May 2010, Brian West wrote:
Please use valgrind and see where its leaking then open a jira.
Nobody has been able to reproduce this in a lab nor provide any details to assist in finding the issue... All I have seen is people complaining about it and not doing what they should debugging the issue and reporting it.
/b
_______________________________________________ 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
-- Anthony Minessale II FreeSWITCH http://www.freeswitch.org/ ClueCon http://www.cluecon.com/ Twitter: http://twitter.com/FreeSWITCH_wire AIM: anthm MSN:anthony_minessale@hotmail.com <MSN%3Aanthony_minessale@hotmail.com> GTALK/JABBER/PAYPAL:anthony.minessale@gmail.com<PAYPAL%3Aanthony.minessale@gmail.com> IRC: irc.freenode.net #freeswitch FreeSWITCH Developer Conference sip:888@conference.freeswitch.org <sip%3A888@conference.freeswitch.org> googletalk:conf+888@conference.freeswitch.org<googletalk%3Aconf%2B888@conference.freeswitch.org> pstn:+19193869900
It's already on jira - FSMOD-48. Valgrind with --leak-check=full finds nothing. Memory kept growing and growing, I had to restart FS when RSS reached 500M to avoid swap. On Monday 10 May 2010, Anthony Minessale wrote:
Why does this thread continue on the list instead of being opened in JIRA Can you see how this issue can be forgotten because it's on the mailing list that gets 200 emails a day? When you show the code in the body of an email like that, then I have to spend a minuted wondering where in the code you were talking about because it's not in the form of a unified diff.
I appreciate that you do not normally have to deal with organized software management but I must ask that you please spend a little time to learn our customs and use JIRA and patches to communicate bug reports. I am glad you are helping to find problems but we really need to stay organized to make it forward.
I redid the function in latest GIT. It did look like it was doing a few things wrong but they probably would have surfaced in valgrind if you were running it in full leak check mode. When you say it goes to 300M, does it keep going from there because there is a bit of memory that will be pooled as you start to use more advanced features. Did you ever watch it to see how high it will go?
On Sun, May 9, 2010 at 4:01 PM, Sergey Okhapkin <sos@sokhapkin.dyndns.org>wrote:
Shouldn't label "end:" be BEFORE switch_odbc_statement_handle_free(&stmt); ? I think it should...
static switch_status_t bill_event( ....
if (switch_odbc_handle_exec(globals.master_odbc, sql, &stmt, NULL) != SWITCH_ODBC_SUCCESS) { char *err_str; err_str = switch_odbc_handle_get_error(globals.master_odbc, stmt); switch_log_printf(SWITCH_CHANNEL_LOG, SWITCH_LOG_ERROR, "ERR: [%s]\n[%s]\n", sql, switch_str_nil(err_str)); switch_safe_free(err_str); } else { /* TODO: Failover to a flat/text file if DB is unavailable */
goto end; }
switch_odbc_statement_handle_free(&stmt);
end:
On Sunday 09 May 2010, Brian West wrote:
What are you calling significant memory usage?
/b
On May 9, 2010, at 2:10 PM, Sergey Okhapkin wrote:
Valgrind output shows no significant leaks. This was discussed already
in
this thread a month ago.
On Sunday 09 May 2010, Brian West wrote:
Please use valgrind and see where its leaking then open a jira.
Nobody has been able to reproduce this in a lab nor provide any
details
to assist in finding the issue... All I have seen is people
complaining
about it and not doing what they should debugging the issue and reporting it.
/b
_______________________________________________ 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
ok so you don't know for sure then, this is obviously a small box. My browser right now is using 500m to let me write this email to you. if you find nothing, it would suggest pools growing more than a real leak since valgrind would normally pick it up. I did not make this nibble bill module but I did correct the code in the place you pointed out. Give it a try. I wish I could nibble-bill this mailing list =p On Mon, May 10, 2010 at 11:14 AM, Sergey Okhapkin <sos@sokhapkin.dyndns.org>wrote:
It's already on jira - FSMOD-48. Valgrind with --leak-check=full finds nothing.
Memory kept growing and growing, I had to restart FS when RSS reached 500M to avoid swap.
On Monday 10 May 2010, Anthony Minessale wrote:
Why does this thread continue on the list instead of being opened in JIRA Can you see how this issue can be forgotten because it's on the mailing list that gets 200 emails a day? When you show the code in the body of an email like that, then I have to spend a minuted wondering where in the code you were talking about because it's not in the form of a unified diff.
I appreciate that you do not normally have to deal with organized software management but I must ask that you please spend a little time to learn our customs and use JIRA and patches to communicate bug reports. I am glad you are helping to find problems but we really need to stay organized to make it forward.
I redid the function in latest GIT. It did look like it was doing a few things wrong but they probably would have surfaced in valgrind if you were running it in full leak check mode. When you say it goes to 300M, does it keep going from there because there is a bit of memory that will be pooled as you start to use more advanced features. Did you ever watch it to see how high it will go?
On Sun, May 9, 2010 at 4:01 PM, Sergey Okhapkin <sos@sokhapkin.dyndns.org>wrote:
Shouldn't label "end:" be BEFORE switch_odbc_statement_handle_free(&stmt); ? I think it should...
static switch_status_t bill_event( ....
if (switch_odbc_handle_exec(globals.master_odbc, sql, &stmt, NULL) != SWITCH_ODBC_SUCCESS) { char *err_str; err_str = switch_odbc_handle_get_error(globals.master_odbc, stmt); switch_log_printf(SWITCH_CHANNEL_LOG, SWITCH_LOG_ERROR, "ERR: [%s]\n[%s]\n", sql, switch_str_nil(err_str)); switch_safe_free(err_str); } else { /* TODO: Failover to a flat/text file if DB is unavailable */
goto end; }
switch_odbc_statement_handle_free(&stmt);
end:
On Sunday 09 May 2010, Brian West wrote:
What are you calling significant memory usage?
/b
On May 9, 2010, at 2:10 PM, Sergey Okhapkin wrote:
Valgrind output shows no significant leaks. This was discussed already
in
this thread a month ago.
On Sunday 09 May 2010, Brian West wrote:
Please use valgrind and see where its leaking then open a jira.
Nobody has been able to reproduce this in a lab nor provide any
details
to assist in finding the issue... All I have seen is people
complaining
about it and not doing what they should debugging the issue and reporting it.
/b
_______________________________________________ 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
-- Anthony Minessale II FreeSWITCH http://www.freeswitch.org/ ClueCon http://www.cluecon.com/ Twitter: http://twitter.com/FreeSWITCH_wire AIM: anthm MSN:anthony_minessale@hotmail.com <MSN%3Aanthony_minessale@hotmail.com> GTALK/JABBER/PAYPAL:anthony.minessale@gmail.com<PAYPAL%3Aanthony.minessale@gmail.com> IRC: irc.freenode.net #freeswitch FreeSWITCH Developer Conference sip:888@conference.freeswitch.org <sip%3A888@conference.freeswitch.org> googletalk:conf+888@conference.freeswitch.org<googletalk%3Aconf%2B888@conference.freeswitch.org> pstn:+19193869900
Sergey: Did you tried the latest code of nibbliebill? and did it fix your problem? On Tue, May 11, 2010 at 12:23 AM, Anthony Minessale < anthony.minessale@gmail.com> wrote:
ok so you don't know for sure then, this is obviously a small box. My browser right now is using 500m to let me write this email to you.
if you find nothing, it would suggest pools growing more than a real leak since valgrind would normally pick it up. I did not make this nibble bill module but I did correct the code in the place you pointed out. Give it a try.
I wish I could nibble-bill this mailing list =p
On Mon, May 10, 2010 at 11:14 AM, Sergey Okhapkin < sos@sokhapkin.dyndns.org> wrote:
It's already on jira - FSMOD-48. Valgrind with --leak-check=full finds nothing.
Memory kept growing and growing, I had to restart FS when RSS reached 500M to avoid swap.
On Monday 10 May 2010, Anthony Minessale wrote:
Why does this thread continue on the list instead of being opened in JIRA Can you see how this issue can be forgotten because it's on the mailing list that gets 200 emails a day? When you show the code in the body of an email like that, then I have to spend a minuted wondering where in the code you were talking about because it's not in the form of a unified diff.
I appreciate that you do not normally have to deal with organized software management but I must ask that you please spend a little time to learn our customs and use JIRA and patches to communicate bug reports. I am glad you are helping to find problems but we really need to stay organized to make it forward.
I redid the function in latest GIT. It did look like it was doing a few things wrong but they probably would have surfaced in valgrind if you were running it in full leak check mode. When you say it goes to 300M, does it keep going from there because there is a bit of memory that will be pooled as you start to use more advanced features. Did you ever watch it to see how high it will go?
On Sun, May 9, 2010 at 4:01 PM, Sergey Okhapkin <sos@sokhapkin.dyndns.org>wrote:
Shouldn't label "end:" be BEFORE switch_odbc_statement_handle_free(&stmt); ? I think it should...
static switch_status_t bill_event( ....
if (switch_odbc_handle_exec(globals.master_odbc, sql, &stmt, NULL) != SWITCH_ODBC_SUCCESS) { char *err_str; err_str = switch_odbc_handle_get_error(globals.master_odbc, stmt); switch_log_printf(SWITCH_CHANNEL_LOG, SWITCH_LOG_ERROR, "ERR: [%s]\n[%s]\n", sql, switch_str_nil(err_str)); switch_safe_free(err_str); } else { /* TODO: Failover to a flat/text file if DB is unavailable */
goto end; }
switch_odbc_statement_handle_free(&stmt);
end:
On Sunday 09 May 2010, Brian West wrote:
What are you calling significant memory usage?
/b
On May 9, 2010, at 2:10 PM, Sergey Okhapkin wrote:
Valgrind output shows no significant leaks. This was discussed already
in
this thread a month ago.
On Sunday 09 May 2010, Brian West wrote: > Please use valgrind and see where its leaking then open a jira. > > Nobody has been able to reproduce this in a lab nor provide any
details
> to assist in finding the issue... All I have seen is people
complaining
> about it and not doing what they should debugging the issue and > reporting it. > > /b
_______________________________________________ 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
-- Anthony Minessale II
FreeSWITCH http://www.freeswitch.org/ ClueCon http://www.cluecon.com/ Twitter: http://twitter.com/FreeSWITCH_wire
AIM: anthm MSN:anthony_minessale@hotmail.com <MSN%3Aanthony_minessale@hotmail.com> GTALK/JABBER/PAYPAL:anthony.minessale@gmail.com<PAYPAL%3Aanthony.minessale@gmail.com> IRC: irc.freenode.net #freeswitch
FreeSWITCH Developer Conference sip:888@conference.freeswitch.org <sip%3A888@conference.freeswitch.org> googletalk:conf+888@conference.freeswitch.org<googletalk%3Aconf%2B888@conference.freeswitch.org> pstn:+19193869900
_______________________________________________ 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
-- Henry Huang UniC Solution - Communication Unified VoIP & Open Source software Consultant
I didn't try yesterday Anthony's update, but his previous fix works OK. Please note that comments in nibblebill config file and default actions in nibblebill code for lowbal_action, nobal_action and percall_action are incorrect, the parameters are not the applications to execute, but dialplan extensions to transfer the call to. On Wednesday 12 May 2010, Henry Huang wrote:
Sergey:
Did you tried the latest code of nibbliebill? and did it fix your problem?
On Tue, May 11, 2010 at 12:23 AM, Anthony Minessale <
anthony.minessale@gmail.com> wrote:
ok so you don't know for sure then, this is obviously a small box. My browser right now is using 500m to let me write this email to you.
if you find nothing, it would suggest pools growing more than a real leak since valgrind would normally pick it up. I did not make this nibble bill module but I did correct the code in the place you pointed out. Give it a try.
I wish I could nibble-bill this mailing list =p
On Mon, May 10, 2010 at 11:14 AM, Sergey Okhapkin <
sos@sokhapkin.dyndns.org> wrote:
It's already on jira - FSMOD-48. Valgrind with --leak-check=full finds nothing.
Memory kept growing and growing, I had to restart FS when RSS reached 500M to avoid swap.
On Monday 10 May 2010, Anthony Minessale wrote:
Why does this thread continue on the list instead of being opened in
JIRA
Can you see how this issue can be forgotten because it's on the mailing list that gets 200 emails a day? When you show the code in the body of an email like that, then I have to spend a minuted wondering where in the code you were talking about
because
it's not in the form of a unified diff.
I appreciate that you do not normally have to deal with organized
software
management but I must ask that you please spend a little time to learn
our
customs and use JIRA and patches to communicate bug reports. I am glad
you
are helping to find problems but we really need to stay organized to
make
it forward.
I redid the function in latest GIT. It did look like it was doing a few things wrong but they probably would have surfaced in valgrind if you
were
running it in full leak check mode. When you say it goes to 300M, does
it
keep going from there because there is a bit of memory that will be
pooled
as you start to use more advanced features. Did you ever watch it to
see
how high it will go?
On Sun, May 9, 2010 at 4:01 PM, Sergey Okhapkin
<sos@sokhapkin.dyndns.org>wrote:
Shouldn't label "end:" be BEFORE switch_odbc_statement_handle_free(&stmt); ? I think it should...
static switch_status_t bill_event( ....
if (switch_odbc_handle_exec(globals.master_odbc, sql, &stmt,
NULL)
!= SWITCH_ODBC_SUCCESS) { char *err_str; err_str = switch_odbc_handle_get_error(globals.master_odbc, stmt); switch_log_printf(SWITCH_CHANNEL_LOG, SWITCH_LOG_ERROR, "ERR: [%s]\n[%s]\n", sql, switch_str_nil(err_str)); switch_safe_free(err_str); } else { /* TODO: Failover to a flat/text file if DB is
unavailable
*/
goto end; }
switch_odbc_statement_handle_free(&stmt);
end:
On Sunday 09 May 2010, Brian West wrote:
What are you calling significant memory usage?
/b
On May 9, 2010, at 2:10 PM, Sergey Okhapkin wrote: > Valgrind output shows no significant leaks. This was discussed > already
in
> this thread a month ago. > > On Sunday 09 May 2010, Brian West wrote: >> Please use valgrind and see where its leaking then open a jira. >> >> Nobody has been able to reproduce this in a lab nor provide any
details
>> to assist in finding the issue... All I have seen is people
complaining
>> about it and not doing what they should debugging the issue and >> reporting it. >> >> /b
_______________________________________________ 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
_______________________________________________ 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
_______________________________________________ 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
-- Anthony Minessale II
FreeSWITCH http://www.freeswitch.org/ ClueCon http://www.cluecon.com/ Twitter: http://twitter.com/FreeSWITCH_wire
AIM: anthm MSN:anthony_minessale@hotmail.com <MSN%3Aanthony_minessale@hotmail.com> GTALK/JABBER/PAYPAL:anthony.minessale@gmail.com<PAYPAL%3Aanthony.minessal e@gmail.com> IRC: irc.freenode.net #freeswitch
FreeSWITCH Developer Conference sip:888@conference.freeswitch.org <sip%3A888@conference.freeswitch.org> googletalk:conf+888@conference.freeswitch.org<googletalk%3Aconf%2B888@con ference.freeswitch.org> pstn:+19193869900
_______________________________________________ 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
Sergey: just making sure. When you say it works okay, did you mean the memory leak stopped? On Wed, May 12, 2010 at 6:23 PM, Sergey Okhapkin <sos@sokhapkin.dyndns.org>wrote:
I didn't try yesterday Anthony's update, but his previous fix works OK.
Please note that comments in nibblebill config file and default actions in nibblebill code for lowbal_action, nobal_action and percall_action are incorrect, the parameters are not the applications to execute, but dialplan extensions to transfer the call to.
On Wednesday 12 May 2010, Henry Huang wrote:
Sergey:
Did you tried the latest code of nibbliebill? and did it fix your problem?
On Tue, May 11, 2010 at 12:23 AM, Anthony Minessale <
anthony.minessale@gmail.com> wrote:
ok so you don't know for sure then, this is obviously a small box. My browser right now is using 500m to let me write this email to you.
if you find nothing, it would suggest pools growing more than a real leak since valgrind would normally pick it up. I did not make this nibble bill module but I did correct the code in the place you pointed out. Give it a try.
I wish I could nibble-bill this mailing list =p
On Mon, May 10, 2010 at 11:14 AM, Sergey Okhapkin <
sos@sokhapkin.dyndns.org> wrote:
It's already on jira - FSMOD-48. Valgrind with --leak-check=full finds nothing.
Memory kept growing and growing, I had to restart FS when RSS reached 500M to avoid swap.
On Monday 10 May 2010, Anthony Minessale wrote:
Why does this thread continue on the list instead of being opened in
JIRA
Can you see how this issue can be forgotten because it's on the mailing list that gets 200 emails a day? When you show the code in the body of an email like that, then I have to spend a minuted wondering where in the code you were talking about
because
it's not in the form of a unified diff.
I appreciate that you do not normally have to deal with organized
software
management but I must ask that you please spend a little time to learn
our
customs and use JIRA and patches to communicate bug reports. I am glad
you
are helping to find problems but we really need to stay organized to
make
it forward.
I redid the function in latest GIT. It did look like it was doing a few things wrong but they probably would have surfaced in valgrind if you
were
running it in full leak check mode. When you say it goes to 300M, does
it
keep going from there because there is a bit of memory that will be
pooled
as you start to use more advanced features. Did you ever watch it to
see
how high it will go?
On Sun, May 9, 2010 at 4:01 PM, Sergey Okhapkin
<sos@sokhapkin.dyndns.org>wrote:
Shouldn't label "end:" be BEFORE switch_odbc_statement_handle_free(&stmt); ? I think it should...
static switch_status_t bill_event( ....
if (switch_odbc_handle_exec(globals.master_odbc, sql, &stmt,
NULL)
!= SWITCH_ODBC_SUCCESS) { char *err_str; err_str = switch_odbc_handle_get_error(globals.master_odbc, stmt); switch_log_printf(SWITCH_CHANNEL_LOG, SWITCH_LOG_ERROR, "ERR: [%s]\n[%s]\n", sql, switch_str_nil(err_str)); switch_safe_free(err_str); } else { /* TODO: Failover to a flat/text file if DB is
unavailable
*/
goto end; }
switch_odbc_statement_handle_free(&stmt);
end:
On Sunday 09 May 2010, Brian West wrote: > What are you calling significant memory usage? > > /b > > On May 9, 2010, at 2:10 PM, Sergey Okhapkin wrote: > > Valgrind output shows no significant leaks. This was discussed > > already
in
> > this thread a month ago. > > > > On Sunday 09 May 2010, Brian West wrote: > >> Please use valgrind and see where its leaking then open a jira. > >> > >> Nobody has been able to reproduce this in a lab nor provide any
details
> >> to assist in finding the issue... All I have seen is people
complaining
> >> about it and not doing what they should debugging the issue and > >> reporting it. > >> > >> /b > > _______________________________________________ > 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
_______________________________________________ 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
_______________________________________________ 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
-- Anthony Minessale II
FreeSWITCH http://www.freeswitch.org/ ClueCon http://www.cluecon.com/ Twitter: http://twitter.com/FreeSWITCH_wire
AIM: anthm MSN:anthony_minessale@hotmail.com<MSN%3Aanthony_minessale@hotmail.com>< MSN%3Aanthony_minessale@hotmail.com<MSN%253Aanthony_minessale@hotmail.com>
GTALK/JABBER/PAYPAL:anthony.minessale@gmail.com<PAYPAL%3Aanthony.minessale@gmail.com> <PAYPAL%3Aanthony.minessal e@gmail.com> IRC: irc.freenode.net #freeswitch
FreeSWITCH Developer Conference sip:888@conference.freeswitch.org<sip%3A888@conference.freeswitch.org>< sip%3A888@conference.freeswitch.org<sip%253A888@conference.freeswitch.org>
googletalk:conf+888@conference.freeswitch.org<googletalk%3Aconf%2B888@conference.freeswitch.org> <googletalk%3Aconf%2B888@con ference.freeswitch.org> pstn:+19193869900
_______________________________________________ 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
-- Henry Huang UniC Solution - Communication Unified VoIP & Open Source software Consultant
Correct, no more unbouded memory growth. On Wednesday 12 May 2010, Henry Huang wrote:
Sergey:
just making sure. When you say it works okay, did you mean the memory leak stopped?
On Wed, May 12, 2010 at 6:23 PM, Sergey Okhapkin
<sos@sokhapkin.dyndns.org>wrote:
I didn't try yesterday Anthony's update, but his previous fix works OK.
Please note that comments in nibblebill config file and default actions in nibblebill code for lowbal_action, nobal_action and percall_action are incorrect, the parameters are not the applications to execute, but dialplan extensions to transfer the call to.
On Wednesday 12 May 2010, Henry Huang wrote:
Sergey:
Did you tried the latest code of nibbliebill? and did it fix your
problem?
On Tue, May 11, 2010 at 12:23 AM, Anthony Minessale <
anthony.minessale@gmail.com> wrote:
ok so you don't know for sure then, this is obviously a small box. My browser right now is using 500m to let me write this email to you.
if you find nothing, it would suggest pools growing more than a real
leak
since valgrind would normally pick it up. I did not make this nibble bill module but I did correct the code in
the
place you pointed out. Give it a try.
I wish I could nibble-bill this mailing list =p
On Mon, May 10, 2010 at 11:14 AM, Sergey Okhapkin <
sos@sokhapkin.dyndns.org> wrote:
It's already on jira - FSMOD-48. Valgrind with --leak-check=full finds nothing.
Memory kept growing and growing, I had to restart FS when RSS reached 500M to avoid swap.
On Monday 10 May 2010, Anthony Minessale wrote:
Why does this thread continue on the list instead of being opened in
JIRA
Can you see how this issue can be forgotten because it's on the mailing list that gets 200 emails a day? When you show the code in the body of an email like that, then I
have
to spend a minuted wondering where in the code you were talking
about
because
it's not in the form of a unified diff.
I appreciate that you do not normally have to deal with organized
software
management but I must ask that you please spend a little time to
learn
our
customs and use JIRA and patches to communicate bug reports. I am glad
you
are helping to find problems but we really need to stay organized to
make
it forward.
I redid the function in latest GIT. It did look like it was doing a few things wrong but they probably would have surfaced in valgrind
if
you
were
running it in full leak check mode. When you say it goes to 300M, does
it
keep going from there because there is a bit of memory that will be
pooled
as you start to use more advanced features. Did you ever watch it
to
see
how high it will go?
On Sun, May 9, 2010 at 4:01 PM, Sergey Okhapkin
<sos@sokhapkin.dyndns.org>wrote:
> Shouldn't label "end:" be BEFORE > switch_odbc_statement_handle_free(&stmt); ? > I think it should... > > > static switch_status_t bill_event( > .... > > if (switch_odbc_handle_exec(globals.master_odbc, sql, > &stmt,
NULL)
> != SWITCH_ODBC_SUCCESS) { > char *err_str; > err_str = > switch_odbc_handle_get_error(globals.master_odbc, stmt); > switch_log_printf(SWITCH_CHANNEL_LOG, > SWITCH_LOG_ERROR, "ERR: > [%s]\n[%s]\n", sql, switch_str_nil(err_str)); > switch_safe_free(err_str); > } else { > /* TODO: Failover to a flat/text file if DB is
unavailable
> */ > > goto end; > } > > switch_odbc_statement_handle_free(&stmt); > > end: > > On Sunday 09 May 2010, Brian West wrote: > > What are you calling significant memory usage? > > > > /b > > > > On May 9, 2010, at 2:10 PM, Sergey Okhapkin wrote: > > > Valgrind output shows no significant leaks. This was > > > discussed already > > in > > > > this thread a month ago. > > > > > > On Sunday 09 May 2010, Brian West wrote: > > >> Please use valgrind and see where its leaking then open a
jira.
> > >> Nobody has been able to reproduce this in a lab nor provide
any
> details > > > >> to assist in finding the issue... All I have seen is people > > complaining > > > >> about it and not doing what they should debugging the issue
and
> > >> reporting it. > > >> > > >> /b > > > > _______________________________________________ > > 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
_______________________________________________ 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
-- Anthony Minessale II
FreeSWITCH http://www.freeswitch.org/ ClueCon http://www.cluecon.com/ Twitter: http://twitter.com/FreeSWITCH_wire
AIM: anthm MSN:anthony_minessale@hotmail.com<MSN%3Aanthony_minessale@hotmail.com
<
MSN%3Aanthony_minessale@hotmail.com<MSN%253Aanthony_minessale@hotmail.com
GTALK/JABBER/PAYPAL:anthony.minessale@gmail.com<PAYPAL%3Aanthony.mine ssale@gmail.com>
<PAYPAL%3Aanthony.minessal
e@gmail.com> IRC: irc.freenode.net #freeswitch
FreeSWITCH Developer Conference sip:888@conference.freeswitch.org<sip%3A888@conference.freeswitch.org
<
sip%3A888@conference.freeswitch.org<sip%253A888@conference.freeswitch.org
googletalk:conf+888@conference.freeswitch.org<googletalk%3Aconf%2B888 @conference.freeswitch.org>
<googletalk%3Aconf%2B888@con
ference.freeswitch.org> pstn:+19193869900
_______________________________________________ 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
_______________________________________________ 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
Hello all, A quick question since the topic of lost sip dialogs was touched: in cases of such dialogs, I assume that FS keeps the reserved memory for the SIP dialog. But what happens when many lost SIP dialogs start to accumulate over time? Does FS have any internal time-out for too old dialogs to declare them dead and release the reserved memory? Best regards, Vlasis Hatzistavrou Monastiriou 9 & Enotikon 54627 Thessaloniki Greece Tel.: +302310556134 Fax: +302310556134 (ext. 0) GSM: +306977835653 e-mail: vhatz@kinetixtele.com http://www.kinetixtele.com Anthony Minessale wrote:
yes its a function of the sofia-sip project, but did you wait before you stopped it? We have people sending non stop 200+calls a second complaining about no leaks. So if you have some real problem it's going to be your network conditions and interop with your providers causing an edge case with the SIP stack itself who has it's own list and irc channel.
On Mon, Apr 19, 2010 at 11:45 AM, Sergey Okhapkin <sos@sokhapkin.dyndns.org <mailto:sos@sokhapkin.dyndns.org>> wrote:
It's possible that some BYE or ACK could be lost, but shouldn't sip dialogs be destroyed automatically after a timeout?
On Monday 19 April 2010, Anthony Minessale wrote: > welll you are losing sip dialogs somewhere. > It's not a leak its loss of sip dialogs most likely a side effect of > topology problems. > > > On Mon, Apr 19, 2010 at 11:03 AM, Sergey Okhapkin > > <sos@sokhapkin.dyndns.org <mailto:sos@sokhapkin.dyndns.org>>wrote: > > The command was exactly as you suggested, FS was started with "-nonat > > -vg" command line options, after few hours run (about 5K calls processed) > > FS was shut down gracefully. > > > > On Monday 19 April 2010, Anthony Minessale wrote: > > > This is invalid. > > > > > > Those places are where sip calls are created and they are most > > > definitely not leaking. > > > If anything, it suggests dialogs that are up still and not yet > > > destroyed > > > > at > > > > > the termination of the program. > > > If this location in the code was a leak it would be gigs not megs > > > > missing. > > > > > Did you do the exact command I said (especially -vg param to FS) and > > > then > > > > a > > > > > full clean shutdown all the way back to the shell? > > > > > > Are you maybe not getting the BYE to your calls creating open dialogs? > > > You may want to turn on the sip trace. > > > > > > > > > On Mon, Apr 19, 2010 at 10:29 AM, Sergey Okhapkin > > > > > > <sos@sokhapkin.dyndns.org <mailto:sos@sokhapkin.dyndns.org>>wrote: > > > > Valgrind doesn't show leaks in mod_nibblebill, most of the leaked > > > > memory > > > > > > was > > > > in mod_sofia: > > > > > > > > ==12476== 53,064 bytes in 67 blocks are definitely lost in loss > > > > record 138 of > > > > 141 > > > > ==12476== at 0x4026378: malloc (in /usr/lib/valgrind/x86- > > > > linux/vgpreload_memcheck.so) > > > > ==12476== by 0x6A0DC8F: sofia_handle_sip_i_invite (sofia.c:6538) > > > > ==12476== > > > > ==12476== > > > > ==12476== 92,664 bytes in 117 blocks are definitely lost in loss > > > > record 139 of > > > > 141 > > > > ==12476== at 0x4026378: malloc (in /usr/lib/valgrind/x86- > > > > linux/vgpreload_memcheck.so) > > > > ==12476== by 0x6A2F76F: sofia_glue_do_invite (sofia_glue.c:1874) > > > > ==12476== > > > > > > > > BTW, do I understand FS code correct that channel private data are > > > > always > > > > > > handled by sqlite, even if I enable core ODBC? > > > > > > > > On Monday 19 April 2010, Anthony Minessale wrote: > > > > > 300M is tiny. try having 2000 channels up you can soar into a gig > > > > > of > > > > > > > > usage. > > > > > > > > > That valgrind report only showed 100k leaked which means it was all > > > > > accounted for and torn down in the end. > > > > > > > > > > If you can find a specific leak in the nibble bill module with > > > > valgrind > > > > > > we > > > > > > > > > will gladly fix it and you > > > > > can gladly thank us for giving you a way to make money by the > > > > > second. > > > > > > > > > > valgrind --tool=memcheck --log-file=vg.log --leak-check=full > > > > > --leak-resolution=high --show-reachable=yes > > > > > /usr/local/freeswitch/bin/freeswitch -vg > > > > > > > > > > > > > > > > > > > > On Sun, Apr 18, 2010 at 11:48 AM, Sergey Okhapkin > > > > > > > > > > <sos@sokhapkin.dyndns.org <mailto:sos@sokhapkin.dyndns.org>>wrote: > > > > > > Which valgrind options should I specify? I did run > > > > > > > > > > > > valgrind --tool=memcheck --log-file=vg.log --leak-check=full > > > > --leak- > > > > > > > > resolution=high --show-reachable=yes ./freeswitch -nonat -vg > > > > > > > > > > > > 100K leaked is nothing compared to FS process RSS of 300M... > > > > > > > > > > > > On Sunday 18 April 2010, Anthony Minessale wrote: > > > > > > > Also thatb suggests you leaked a whopping 100k > > > > > > > > > > > > > > On Apr 18, 2010 11:35 AM, "Anthony Minessale" < > > > > > > > > > > > > anthony.minessale@gmail.com <mailto:anthony.minessale@gmail.com>> > > > > > > > > > > > > > wrote: > > > > > > > > > > > > > > That's not very useful you need a full report with extended > > > > > > > checking. > > > > > > > > > > > > > > > On Apr 18, 2010 7:34 AM, "Sergey Okhapkin" < > > > > > > > > sos@sokhapkin.dyndns.org <mailto:sos@sokhapkin.dyndns.org>> > > > > > > > > > > > wrote: > > > > > > > > According to v... > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > On Saturday 17 April 2010, Michael Jerris wrote: > > > > > > > > That is a completely incorrect statement. Usi... > > > > > > > > > > > > _______________________________________________ > > > > > > FreeSWITCH-users mailing list > > > > > > FreeSWITCH-users@lists.freeswitch.org <mailto: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 <mailto: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 <mailto: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 <mailto: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
-- Anthony Minessale II
FreeSWITCH http://www.freeswitch.org/ ClueCon http://www.cluecon.com/ Twitter: http://twitter.com/FreeSWITCH_wire
AIM: anthm MSN:anthony_minessale@hotmail.com <mailto:MSN%3Aanthony_minessale@hotmail.com> GTALK/JABBER/PAYPAL:anthony.minessale@gmail.com <mailto:PAYPAL%3Aanthony.minessale@gmail.com> IRC: irc.freenode.net <http://irc.freenode.net> #freeswitch
FreeSWITCH Developer Conference sip:888@conference.freeswitch.org <mailto:sip%3A888@conference.freeswitch.org> googletalk:conf+888@conference.freeswitch.org <mailto:googletalk%3Aconf%2B888@conference.freeswitch.org> pstn:+19193869900 ------------------------------------------------------------------------
_______________________________________________ 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
Dialogs are managed by the sofia sip stack. Its a separate project and a seperate library. But it more or less follows the rfc and keeps them for the allotted time and then destroys them unless there is a bug. One such bug exists when enabling 100rel in some specific edge cases for instance..... On Apr 20, 2010 7:35 PM, "Vlasis Hatzistavrou (KTI)" <vhatz@kinetix.gr> wrote: Hello all, A quick question since the topic of lost sip dialogs was touched: in cases of such dialogs, I assume that FS keeps the reserved memory for the SIP dialog. But what happens when many lost SIP dialogs start to accumulate over time? Does FS have any internal time-out for too old dialogs to declare them dead and release the reserved memory? Best regards, Vlasis Hatzistavrou Monastiriou 9 & Enotikon 54627 Thessaloniki Greece Tel.: +302310556134 Fax: +302310556134 (ext. 0) GSM: +306977835653 e-mail: vhatz@kinetixtele.comhttp://www.kinetixtele.com Anthony Minessale wrote:
yes its a function of the sofia-sip project, but did you wait before you
stopped it?
We have ...
------------------------------
_______________________________________________ FreeSWITCH-users mailing list FreeSWITCH-user...
_______________________________________________ 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
participants (9)
-
Anthony Minessale
-
Brian West
-
Gabriel Gunderson
-
Henry Huang
-
Henry Huang
-
Michael Jerris
-
Rupa Schomaker
-
Sergey Okhapkin
-
Vlasis Hatzistavrou (KTI)