Sponsor: VoiceMeUp - Corporate & Wholesale VoIP Services

VoIP Mailing List Archives
Mailing list archives for the VoIP community
 SearchSearch 

[Freeswitch-users] memory leak

Goto page Previous  1, 2
 
Post new topic   Reply to topic    VoIP Mailing List Archives Forum Index -> freeSWITCH Users
View previous topic :: View next topic  
Author Message
fraunhofer.lists.frees...
Guest





PostPosted: Wed Sep 02, 2009 10:42 am    Post subject: [Freeswitch-users] memory leak Reply with quote

Hello Anthony,

2009/9/2 Anthony Minessale <anthony.minessale@gmail.com>:
Quote:
run it slower and make sure it shuts down clean.

i already reduced load 37% but that didnt help, now i'm down to 25%
and it's running.

Quote:
valgrind --tool=memcheck --log-file-exactly=vg.log --leak-check=full
--leak-resolution=high --show-reachable=yes /path/to/freeswitch -vg

that's the line in the wiki? I used that but "log-file-exactly" is not
available in my valgrind-3.3.0-Debian, just "log-file". Does this make
any difference?

Also it wont shut down cleanly but oom-coredump (some assertion
failed) and if i stop the loadgen after some time and try to 'fsctl
shutdown' it wont cleanly bring it down, too. (see first post, last
line printed is

switch_core_memory.c:567 Stopping memory pool queue.
)

Thx.

Beni.

_______________________________________________
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
Back to top
anthony.minessale at g...
Guest





PostPosted: Wed Sep 02, 2009 10:54 am    Post subject: [Freeswitch-users] memory leak Reply with quote

i mean valgrind is very intensive so you must run very slow 1-5cps

yes if you have a version that only has log-file you can use that.

if you find me on irc and send me the credentials privately I will examine your box for you.


On Wed, Sep 2, 2009 at 10:26 AM, Benedikt Fraunhofer <fraunhofer.lists.freeswitch-001@traced.net (fraunhofer.lists.freeswitch-001@traced.net)> wrote:
Quote:
Hello Anthony,

2009/9/2 Anthony Minessale <anthony.minessale@gmail.com (anthony.minessale@gmail.com)>:
Quote:
run it slower and make sure it shuts down clean.


i already reduced load 37% but that didnt help, now i'm down to 25%
and it's running.

Quote:
valgrind --tool=memcheck --log-file-exactly=vg.log --leak-check=full
--leak-resolution=high --show-reachable=yes /path/to/freeswitch -vg


that's the line in the wiki? I used that but "log-file-exactly" is not
available in my valgrind-3.3.0-Debian, just "log-file". Does this make
any difference?

Also it wont shut down cleanly but oom-coredump  (some assertion
failed) and if i stop the loadgen after some time and try to 'fsctl
shutdown' it wont cleanly bring it down, too. (see first post, last
line printed is

 switch_core_memory.c:567 Stopping memory pool queue.

)

Thx.


 Beni.

_______________________________________________
FreeSWITCH-users mailing list
FreeSWITCH-users@lists.freeswitch.org (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 ([email]MSN%3Aanthony_minessale@hotmail.com[/email])
GTALK/JABBER/PAYPAL:anthony.minessale@gmail.com ([email]PAYPAL%3Aanthony.minessale@gmail.com[/email])
IRC: irc.freenode.net #freeswitch

FreeSWITCH Developer Conference
sip:888@conference.freeswitch.org ([email]sip%3A888@conference.freeswitch.org[/email])
iax:guest@conference.freeswitch.org/888
googletalk:conf+888@conference.freeswitch.org ([email]googletalk%3Aconf%2B888@conference.freeswitch.org[/email])
pstn:213-799-1400
Back to top
fraunhofer.lists.frees...
Guest





PostPosted: Fri Sep 04, 2009 7:47 am    Post subject: [Freeswitch-users] memory leak Reply with quote

Hello Anthony,

2009/9/2 Anthony Minessale <anthony.minessale@gmail.com>:

Quote:
yes if you have a version that only has log-file you can use that.

if you find me on irc and send me the credentials privately I will examine
your box for you.

thanks for that offer, but the box is pretty deep inside our internal
network with no routing to the outside, several stepping-stones in
between and all that "security" stuff.

I finally found the right amount of load where the memory leak builds
up quickly enough and was able to stop freeswitch before it started
swapping. The result is available on

http://ns42.ath.cx/B0GdWh/vg-2.log.bz2

(19k)

Thx in advance
Beni.

_______________________________________________
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
Back to top
rupa at rupa.com
Guest





PostPosted: Fri Sep 04, 2009 9:27 am    Post subject: [Freeswitch-users] memory leak Reply with quote

Worst offenders (leakers over 100K). The last one is the worst (672M)
-- looks like a lua script. What are you doing in lua again?

==28624== 105,725 bytes in 1,804 blocks are still reachable in loss
record 497 of 529
==28624== at 0x4022AB8: malloc (vg_replace_malloc.c:207)
==28624== by 0x444AFCF: strdup (in /lib/tls/i686/cmov/libc-2.7.so)
==28624== by 0x50384F2: xmlrpc_strdupnull (asprintf.c:92)
==28624== by 0x503F86D: RequestRead (http.c:57)
==28624== by 0x5044413: ??? (server.c:538)
==28624== by 0x5039FAF: ??? (conn.c:37)
==28624== by 0x50486F1: ??? (thread_pthread.c:4Cool
==28624== by 0x42114FA: start_thread (in
/lib/tls/i686/cmov/libpthread-2.7.so)
==28624== by 0x44AFE5D: clone (in /lib/tls/i686/cmov/libc-2.7.so)
==28624==
==28624==
==28624== 116,772 bytes in 3,156 blocks are definitely lost in loss
record 498 of 529
==28624== at 0x4022AB8: malloc (vg_replace_malloc.c:207)
==28624== by 0x444AFCF: strdup (in /lib/tls/i686/cmov/libc-2.7.so)
==28624== by 0x40E4EA9: switch_log_vprintf (switch_log.c:438)
==28624== by 0x40E5130: switch_log_printf (switch_log.c:308)
==28624== by 0x4088664: switch_channel_perform_hangup (switch_channel.c:1674)
==28624== by 0x64A12EA: ??? (mod_dptools.c:633)
==28624== by 0x409AA45: switch_core_session_exec (switch_core_session.c:1476)
==28624== by 0x409AF88: switch_core_session_execute_application
(switch_core_session.c:1398)
==28624== by 0x409E674: switch_core_session_run
(switch_core_state_machine.c:166)
==28624== by 0x409A48E: switch_core_session_thread
(switch_core_session.c:1066)
==28624== by 0x4110E05: dummy_worker (thread.c:138)
==28624== by 0x42114FA: start_thread (in
/lib/tls/i686/cmov/libpthread-2.7.so)
==28624==
==28624==
==28624== 119,658 (119,621 direct, 37 indirect) bytes in 3,233 blocks
are definitely lost in loss record 499 of 529
==28624== at 0x4022AB8: malloc (vg_replace_malloc.c:207)
==28624== by 0x444AFCF: strdup (in /lib/tls/i686/cmov/libc-2.7.so)
==28624== by 0x40E4EA9: switch_log_vprintf (switch_log.c:438)
==28624== by 0x40E5130: switch_log_printf (switch_log.c:308)
==28624== by 0x4088664: switch_channel_perform_hangup (switch_channel.c:1674)
==28624== by 0x50B6790: sofia_event_callback (sofia.c:3863)
==28624== by 0x5146787: nua_application_event (nua_stack.c:393)
==28624== by 0x519DB28: su_base_port_execute_msgs (su_base_port.c:280)
==28624== by 0x519D8CF: su_base_port_getmsgs (su_base_port.c:202)
==28624== by 0x519DD75: su_base_port_step (su_base_port.c:454)
==28624== by 0x5190968: su_port_step (su_port.h:340)
==28624== by 0x5190938: su_root_step (su_root.c:858)
==28624==
==28624==
==28624== 124,209 bytes in 3,357 blocks are still reachable in loss
record 500 of 529
==28624== at 0x4022AB8: malloc (vg_replace_malloc.c:207)
==28624== by 0x444AFCF: strdup (in /lib/tls/i686/cmov/libc-2.7.so)
==28624== by 0x40E4EA9: switch_log_vprintf (switch_log.c:438)
==28624== by 0x40E5130: switch_log_printf (switch_log.c:308)
==28624== by 0x409A5EC: switch_core_session_thread
(switch_core_session.c:1086)
==28624== by 0x4110E05: dummy_worker (thread.c:138)
==28624== by 0x42114FA: start_thread (in
/lib/tls/i686/cmov/libpthread-2.7.so)
==28624== by 0x44AFE5D: clone (in /lib/tls/i686/cmov/libc-2.7.so)
==28624==
==28624==
==28624== 124,290 bytes in 4,143 blocks are still reachable in loss
record 501 of 529
==28624== at 0x4022AB8: malloc (vg_replace_malloc.c:207)
==28624== by 0x443B957: vasprintf (in /lib/tls/i686/cmov/libc-2.7.so)
==28624== by 0x5038532: xmlrpc_vasprintf (asprintf.c:61)
==28624== by 0x5038581: xmlrpc_asprintf (asprintf.c:81)
==28624== by 0x503B881: DateToString (date.c:43)
==28624== by 0x5036D09: handler_hook (mod_xml_rpc.c:733)
==28624== by 0x504456F: ??? (server.c:515)
==28624== by 0x5039FAF: ??? (conn.c:37)
==28624== by 0x50486F1: ??? (thread_pthread.c:4Cool
==28624== by 0x42114FA: start_thread (in
/lib/tls/i686/cmov/libpthread-2.7.so)
==28624== by 0x44AFE5D: clone (in /lib/tls/i686/cmov/libc-2.7.so)
==28624==
==28624==
==28624== 137,085 bytes in 3,705 blocks are still reachable in loss
record 502 of 529
==28624== at 0x4022AB8: malloc (vg_replace_malloc.c:207)
==28624== by 0x444AFCF: strdup (in /lib/tls/i686/cmov/libc-2.7.so)
==28624== by 0x40E4EA9: switch_log_vprintf (switch_log.c:438)
==28624== by 0x40E5130: switch_log_printf (switch_log.c:308)
==28624== by 0x409921F: switch_core_session_perform_destroy
(switch_core_session.c:947)
==28624== by 0x409A60D: switch_core_session_thread
(switch_core_session.c:1088)
==28624== by 0x4110E05: dummy_worker (thread.c:138)
==28624== by 0x42114FA: start_thread (in
/lib/tls/i686/cmov/libpthread-2.7.so)
==28624== by 0x44AFE5D: clone (in /lib/tls/i686/cmov/libc-2.7.so)
==28624==
==28624==
==28624== 145,589 bytes in 1,837 blocks are possibly lost in loss
record 503 of 529
==28624== at 0x4022AB8: malloc (vg_replace_malloc.c:207)
==28624== by 0x444AFCF: strdup (in /lib/tls/i686/cmov/libc-2.7.so)
==28624== by 0x50384F2: xmlrpc_strdupnull (asprintf.c:92)
==28624== by 0x503F86D: RequestRead (http.c:57)
==28624== by 0x5044413: ??? (server.c:538)
==28624== by 0x5039FAF: ??? (conn.c:37)
==28624== by 0x50486F1: ??? (thread_pthread.c:4Cool
==28624== by 0x42114FA: start_thread (in
/lib/tls/i686/cmov/libpthread-2.7.so)
==28624== by 0x44AFE5D: clone (in /lib/tls/i686/cmov/libc-2.7.so)
==28624==
==28624==
==28624== 151,929 (151,922 direct, 7 indirect) bytes in 4,106 blocks
are definitely lost in loss record 504 of 529
==28624== at 0x4022AB8: malloc (vg_replace_malloc.c:207)
==28624== by 0x444AFCF: strdup (in /lib/tls/i686/cmov/libc-2.7.so)
==28624== by 0x40E4EA9: switch_log_vprintf (switch_log.c:438)
==28624== by 0x40E5130: switch_log_printf (switch_log.c:308)
==28624== by 0x4088664: switch_channel_perform_hangup (switch_channel.c:1674)
==28624== by 0x40C124A: audio_bridge_on_exchange_media
(switch_ivr_bridge.c:503)
==28624== by 0x409DB8B: switch_core_session_run
(switch_core_state_machine.c:494)
==28624== by 0x409A48E: switch_core_session_thread
(switch_core_session.c:1066)
==28624== by 0x4110E05: dummy_worker (thread.c:138)
==28624== by 0x42114FA: start_thread (in
/lib/tls/i686/cmov/libpthread-2.7.so)
==28624== by 0x44AFE5D: clone (in /lib/tls/i686/cmov/libc-2.7.so)
==28624==
==28624==
==28624== 200,704 bytes in 1 blocks are still reachable in loss record
505 of 529
==28624== at 0x4022AB8: malloc (vg_replace_malloc.c:207)
==28624== by 0x410C0EC: apr_palloc (apr_pools.c:300)
==28624== by 0x4101A3A: apr_queue_create (apr_queue.c:129)
==28624== by 0x407FFEA: switch_queue_create (switch_apr.c:897)
==28624== by 0x509F2B5: mod_sofia_load (mod_sofia.c:3371)
==28624== by 0x40AF30D: switch_loadable_module_load_module_ex
(switch_loadable_module.c:846)
==28624== by 0x40AFCCF: switch_loadable_module_init
(switch_loadable_module.c:1174)
==28624== by 0x40A8320: switch_core_init_and_modload (switch_core.c:1451)
==28624== by 0x804A7EC: main (switch.c:731)
==28624==
==28624==
==28624== 200,704 bytes in 1 blocks are still reachable in loss record
506 of 529
==28624== at 0x4022AB8: malloc (vg_replace_malloc.c:207)
==28624== by 0x410C0EC: apr_palloc (apr_pools.c:300)
==28624== by 0x4101A3A: apr_queue_create (apr_queue.c:129)
==28624== by 0x407FFEA: switch_queue_create (switch_apr.c:897)
==28624== by 0x509F295: mod_sofia_load (mod_sofia.c:3370)
==28624== by 0x40AF30D: switch_loadable_module_load_module_ex
(switch_loadable_module.c:846)
==28624== by 0x40AFCCF: switch_loadable_module_init
(switch_loadable_module.c:1174)
==28624== by 0x40A8320: switch_core_init_and_modload (switch_core.c:1451)
==28624== by 0x804A7EC: main (switch.c:731)
==28624==
==28624==
==28624== 225,280 bytes in 11 blocks are still reachable in loss
record 507 of 529
==28624== at 0x4022AB8: malloc (vg_replace_malloc.c:207)
==28624== by 0x503AC39: ??? (mallocvar.h:43)
==28624== by 0x503ACBD: PoolAlloc (data.c:602)
==28624== by 0x503AD2C: PoolStrdup (data.c:674)
==28624== by 0x5043442: MIMETypeAdd2 (response.c:356)
==28624== by 0x50434DD: MIMETypeAdd (response.c:415)
==28624== by 0x503586D: mod_xml_rpc_runtime (mod_xml_rpc.c:936)
==28624== by 0x40AF772: switch_loadable_module_exec
(switch_loadable_module.c:94)
==28624== by 0x4110E05: dummy_worker (thread.c:138)
==28624== by 0x42114FA: start_thread (in
/lib/tls/i686/cmov/libpthread-2.7.so)
==28624== by 0x44AFE5D: clone (in /lib/tls/i686/cmov/libc-2.7.so)
==28624==
==28624==
==28624== 246,312 bytes in 311 blocks are possibly lost in loss record
508 of 529
==28624== at 0x4022AB8: malloc (vg_replace_malloc.c:207)
==28624== by 0x50D7759: sofia_glue_do_invite (sofia_glue.c:1677)
==28624== by 0x50A2400: sofia_on_init (mod_sofia.c:102)
==28624== by 0x409D587: switch_core_session_run
(switch_core_state_machine.c:481)
==28624== by 0x409A48E: switch_core_session_thread
(switch_core_session.c:1066)
==28624== by 0x4110E05: dummy_worker (thread.c:138)
==28624== by 0x42114FA: start_thread (in
/lib/tls/i686/cmov/libpthread-2.7.so)
==28624== by 0x44AFE5D: clone (in /lib/tls/i686/cmov/libc-2.7.so)
==28624==
==28624==
==28624== 303,104 bytes in 37 blocks are still reachable in loss
record 509 of 529
==28624== at 0x4022AB8: malloc (vg_replace_malloc.c:207)
==28624== by 0x410BB2F: apr_pool_create_ex (apr_pools.c:300)
==28624== by 0x4092416: switch_core_perform_new_memory_pool
(switch_core_memory.c:357)
==28624== by 0x40AF24E: switch_loadable_module_load_module_ex
(switch_loadable_module.c:785)
==28624== by 0x40AFCCF: switch_loadable_module_init
(switch_loadable_module.c:1174)
==28624== by 0x40A8320: switch_core_init_and_modload (switch_core.c:1451)
==28624== by 0x804A7EC: main (switch.c:731)
==28624==
==28624==
==28624== 399,637 (399,600 direct, 37 indirect) bytes in 10,800 blocks
are definitely lost in loss record 510 of 529
==28624== at 0x4022AB8: malloc (vg_replace_malloc.c:207)
==28624== by 0x444AFCF: strdup (in /lib/tls/i686/cmov/libc-2.7.so)
==28624== by 0x40E4EA9: switch_log_vprintf (switch_log.c:438)
==28624== by 0x40E5130: switch_log_printf (switch_log.c:308)
==28624== by 0x4088664: switch_channel_perform_hangup (switch_channel.c:1674)
==28624== by 0x50B2A5E: sofia_handle_sip_i_bye (sofia.c:327)
==28624== by 0x50B4A76: sofia_event_callback (sofia.c:508)
==28624== by 0x5146787: nua_application_event (nua_stack.c:393)
==28624== by 0x519DB28: su_base_port_execute_msgs (su_base_port.c:280)
==28624== by 0x519D8CF: su_base_port_getmsgs (su_base_port.c:202)
==28624== by 0x519DD75: su_base_port_step (su_base_port.c:454)
==28624== by 0x5190968: su_port_step (su_port.h:340)
==28624==
==28624==
==28624== 444,777 bytes in 12,021 blocks are definitely lost in loss
record 511 of 529
==28624== at 0x4022AB8: malloc (vg_replace_malloc.c:207)
==28624== by 0x444AFCF: strdup (in /lib/tls/i686/cmov/libc-2.7.so)
==28624== by 0x40E4EA9: switch_log_vprintf (switch_log.c:438)
==28624== by 0x40E5130: switch_log_printf (switch_log.c:308)
==28624== by 0x4088664: switch_channel_perform_hangup (switch_channel.c:1674)
==28624== by 0x50B6790: sofia_event_callback (sofia.c:3863)
==28624== by 0x5146787: nua_application_event (nua_stack.c:393)
==28624== by 0x519DB28: su_base_port_execute_msgs (su_base_port.c:280)
==28624== by 0x519D8CF: su_base_port_getmsgs (su_base_port.c:202)
==28624== by 0x519DE27: su_base_port_step (su_base_port.c:473)
==28624== by 0x5190968: su_port_step (su_port.h:340)
==28624== by 0x5190938: su_root_step (su_root.c:858)
==28624==
==28624==
==28624== 2,261,847 (2,261,810 direct, 37 indirect) bytes in 61,130
blocks are definitely lost in loss record 512 of 529
==28624== at 0x4022AB8: malloc (vg_replace_malloc.c:207)
==28624== by 0x444AFCF: strdup (in /lib/tls/i686/cmov/libc-2.7.so)
==28624== by 0x40E4EA9: switch_log_vprintf (switch_log.c:438)
==28624== by 0x40E5130: switch_log_printf (switch_log.c:308)
==28624== by 0x408A4B7: switch_channel_perform_mark_answered
(switch_channel.c:1914)
==28624== by 0x50B8528: sofia_event_callback (sofia.c:3807)
==28624== by 0x5146787: nua_application_event (nua_stack.c:393)
==28624== by 0x519DB28: su_base_port_execute_msgs (su_base_port.c:280)
==28624== by 0x519D8CF: su_base_port_getmsgs (su_base_port.c:202)
==28624== by 0x519DD75: su_base_port_step (su_base_port.c:454)
==28624== by 0x5190968: su_port_step (su_port.h:340)
==28624== by 0x5190938: su_root_step (su_root.c:858)
==28624==
==28624==
==28624== 2,413,880 (2,413,843 direct, 37 indirect) bytes in 65,239
blocks are definitely lost in loss record 513 of 529
==28624== at 0x4022AB8: malloc (vg_replace_malloc.c:207)
==28624== by 0x444AFCF: strdup (in /lib/tls/i686/cmov/libc-2.7.so)
==28624== by 0x40E4EA9: switch_log_vprintf (switch_log.c:438)
==28624== by 0x40E5130: switch_log_printf (switch_log.c:308)
==28624== by 0x4088664: switch_channel_perform_hangup (switch_channel.c:1674)
==28624== by 0x50B2A5E: sofia_handle_sip_i_bye (sofia.c:327)
==28624== by 0x50B4A76: sofia_event_callback (sofia.c:508)
==28624== by 0x5146787: nua_application_event (nua_stack.c:393)
==28624== by 0x519DB28: su_base_port_execute_msgs (su_base_port.c:280)
==28624== by 0x519D8CF: su_base_port_getmsgs (su_base_port.c:202)
==28624== by 0x519DE27: su_base_port_step (su_base_port.c:473)
==28624== by 0x5190968: su_port_step (su_port.h:340)
==28624==
==28624==
==28624== 2,416,640 bytes in 295 blocks are still reachable in loss
record 514 of 529
==28624== at 0x4022AB8: malloc (vg_replace_malloc.c:207)
==28624== by 0x410C0EC: apr_palloc (apr_pools.c:300)
==28624== by 0x41110E6: apr_thread_create (thread.c:150)
==28624== by 0x4080878: switch_thread_create (switch_apr.c:631)
==28624== by 0x6C278E9: lua_thread (mod_lua.cpp:372)
==28624== by 0x6C27948: ??? (mod_lua.cpp:407)
==28624== by 0x40AADFC: switch_api_execute (switch_loadable_module.c:1567)
==28624== by 0x583A7FC: ??? (mod_commands.c:2426)
==28624== by 0x40A8881: switch_scheduler_execute (switch_scheduler.c:61)
==28624== by 0x40A8DE0: task_thread_loop (switch_scheduler.c:127)
==28624== by 0x40A8EA3: switch_scheduler_task_thread (switch_scheduler.c:168)
==28624== by 0x4110E05: dummy_worker (thread.c:138)
==28624==
==28624==
==28624== 2,671,215 (2,671,178 direct, 37 indirect) bytes in 72,194
blocks are definitely lost in loss record 515 of 529
==28624== at 0x4022AB8: malloc (vg_replace_malloc.c:207)
==28624== by 0x444AFCF: strdup (in /lib/tls/i686/cmov/libc-2.7.so)
==28624== by 0x40E4EA9: switch_log_vprintf (switch_log.c:438)
==28624== by 0x40E5130: switch_log_printf (switch_log.c:308)
==28624== by 0x408ACF4: switch_channel_perform_mark_ring_ready
(switch_channel.c:1697)
==28624== by 0x50B6E29: sofia_event_callback (sofia.c:3366)
==28624== by 0x5146787: nua_application_event (nua_stack.c:393)
==28624== by 0x519DB28: su_base_port_execute_msgs (su_base_port.c:280)
==28624== by 0x519D8CF: su_base_port_getmsgs (su_base_port.c:202)
==28624== by 0x519DD75: su_base_port_step (su_base_port.c:454)
==28624== by 0x5190968: su_port_step (su_port.h:340)
==28624== by 0x5190938: su_root_step (su_root.c:858)
==28624==
==28624==
==28624== 2,826,171 bytes in 76,383 blocks are definitely lost in loss
record 516 of 529
==28624== at 0x4022AB8: malloc (vg_replace_malloc.c:207)
==28624== by 0x444AFCF: strdup (in /lib/tls/i686/cmov/libc-2.7.so)
==28624== by 0x40E4EA9: switch_log_vprintf (switch_log.c:438)
==28624== by 0x40E5130: switch_log_printf (switch_log.c:308)
==28624== by 0x4088664: switch_channel_perform_hangup (switch_channel.c:1674)
==28624== by 0x40C1049: signal_bridge_on_hangup (switch_ivr_bridge.c:710)
==28624== by 0x409D7CF: switch_core_session_run
(switch_core_state_machine.c:434)
==28624== by 0x409A48E: switch_core_session_thread
(switch_core_session.c:1066)
==28624== by 0x4110E05: dummy_worker (thread.c:138)
==28624== by 0x42114FA: start_thread (in
/lib/tls/i686/cmov/libpthread-2.7.so)
==28624== by 0x44AFE5D: clone (in /lib/tls/i686/cmov/libc-2.7.so)
==28624==
==28624==
==28624== 2,968,658 bytes in 80,234 blocks are definitely lost in loss
record 517 of 529
==28624== at 0x4022AB8: malloc (vg_replace_malloc.c:207)
==28624== by 0x444AFCF: strdup (in /lib/tls/i686/cmov/libc-2.7.so)
==28624== by 0x40E4EA9: switch_log_vprintf (switch_log.c:438)
==28624== by 0x40E5130: switch_log_printf (switch_log.c:308)
==28624== by 0x692F07B: ??? (mod_dialplan_xml.c:315)
==28624== by 0x409EFFD: switch_core_session_run
(switch_core_state_machine.c:109)
==28624== by 0x409A48E: switch_core_session_thread
(switch_core_session.c:1066)
==28624== by 0x4110E05: dummy_worker (thread.c:138)
==28624== by 0x42114FA: start_thread (in
/lib/tls/i686/cmov/libpthread-2.7.so)
==28624== by 0x44AFE5D: clone (in /lib/tls/i686/cmov/libc-2.7.so)
==28624==
==28624==
==28624== 2,974,282 (2,974,245 direct, 37 indirect) bytes in 80,385
blocks are definitely lost in loss record 518 of 529
==28624== at 0x4022AB8: malloc (vg_replace_malloc.c:207)
==28624== by 0x444AFCF: strdup (in /lib/tls/i686/cmov/libc-2.7.so)
==28624== by 0x40E4EA9: switch_log_vprintf (switch_log.c:438)
==28624== by 0x40E5130: switch_log_printf (switch_log.c:308)
==28624== by 0x40DDF32: switch_ivr_session_transfer (switch_ivr.c:1350)
==28624== by 0x5840B54: ??? (mod_commands.c:2319)
==28624== by 0x40AADFC: switch_api_execute (switch_loadable_module.c:1567)
==28624== by 0x5036FAA: handler_hook (mod_xml_rpc.c:777)
==28624== by 0x504456F: ??? (server.c:515)
==28624== by 0x5039FAF: ??? (conn.c:37)
==28624== by 0x50486F1: ??? (thread_pthread.c:4Cool
==28624== by 0x42114FA: start_thread (in
/lib/tls/i686/cmov/libpthread-2.7.so)
==28624==
==28624==
==28624== 2,976,983 (2,976,909 direct, 74 indirect) bytes in 80,457
blocks are definitely lost in loss record 519 of 529
==28624== at 0x4022AB8: malloc (vg_replace_malloc.c:207)
==28624== by 0x444AFCF: strdup (in /lib/tls/i686/cmov/libc-2.7.so)
==28624== by 0x40E4EA9: switch_log_vprintf (switch_log.c:438)
==28624== by 0x40E5130: switch_log_printf (switch_log.c:308)
==28624== by 0x408B204: switch_channel_set_name (switch_channel.c:602)
==28624== by 0x50D3FDD: sofia_glue_attach_private (sofia_glue.c:527)
==28624== by 0x50A35EF: sofia_outgoing_channel (mod_sofia.c:2854)
==28624== by 0x409B970: switch_core_session_outgoing_channel
(switch_core_session.c:410)
==28624== by 0x40C53D8: switch_ivr_originate (switch_ivr_originate.c:1508)
==28624== by 0x64A7F2F: ??? (mod_dptools.c:2092)
==28624== by 0x409AA45: switch_core_session_exec (switch_core_session.c:1476)
==28624== by 0x409AF88: switch_core_session_execute_application
(switch_core_session.c:1398)
==28624==
==28624==
==28624== 3,085,393 bytes in 83,389 blocks are definitely lost in loss
record 520 of 529
==28624== at 0x4022AB8: malloc (vg_replace_malloc.c:207)
==28624== by 0x444AFCF: strdup (in /lib/tls/i686/cmov/libc-2.7.so)
==28624== by 0x40E4EA9: switch_log_vprintf (switch_log.c:438)
==28624== by 0x40E5130: switch_log_printf (switch_log.c:308)
==28624== by 0x408ACF4: switch_channel_perform_mark_ring_ready
(switch_channel.c:1697)
==28624== by 0x50B6E29: sofia_event_callback (sofia.c:3366)
==28624== by 0x5146787: nua_application_event (nua_stack.c:393)
==28624== by 0x519DB28: su_base_port_execute_msgs (su_base_port.c:280)
==28624== by 0x519D8CF: su_base_port_getmsgs (su_base_port.c:202)
==28624== by 0x519DE27: su_base_port_step (su_base_port.c:473)
==28624== by 0x5190968: su_port_step (su_port.h:340)
==28624== by 0x5190938: su_root_step (su_root.c:858)
==28624==
==28624==
==28624== 3,110,961 (3,107,016 direct, 3,945 indirect) bytes in 3,923
blocks are definitely lost in loss record 521 of 529
==28624== at 0x4022AB8: malloc (vg_replace_malloc.c:207)
==28624== by 0x50D7759: sofia_glue_do_invite (sofia_glue.c:1677)
==28624== by 0x50A2400: sofia_on_init (mod_sofia.c:102)
==28624== by 0x409D587: switch_core_session_run
(switch_core_state_machine.c:481)
==28624== by 0x409A48E: switch_core_session_thread
(switch_core_session.c:1066)
==28624== by 0x4110E05: dummy_worker (thread.c:138)
==28624== by 0x42114FA: start_thread (in
/lib/tls/i686/cmov/libpthread-2.7.so)
==28624== by 0x44AFE5D: clone (in /lib/tls/i686/cmov/libc-2.7.so)
==28624==
==28624==
==28624== 3,550,402 (3,550,261 direct, 141 indirect) bytes in 95,953
blocks are definitely lost in loss record 522 of 529
==28624== at 0x4022AB8: malloc (vg_replace_malloc.c:207)
==28624== by 0x444AFCF: strdup (in /lib/tls/i686/cmov/libc-2.7.so)
==28624== by 0x40E4EA9: switch_log_vprintf (switch_log.c:438)
==28624== by 0x40E5130: switch_log_printf (switch_log.c:308)
==28624== by 0x408B204: switch_channel_set_name (switch_channel.c:602)
==28624== by 0x50D3FDD: sofia_glue_attach_private (sofia_glue.c:527)
==28624== by 0x50A35EF: sofia_outgoing_channel (mod_sofia.c:2854)
==28624== by 0x409B970: switch_core_session_outgoing_channel
(switch_core_session.c:410)
==28624== by 0x40C53D8: switch_ivr_originate (switch_ivr_originate.c:1508)
==28624== by 0x5840AF1: ??? (mod_commands.c:2285)
==28624== by 0x40AADFC: switch_api_execute (switch_loadable_module.c:1567)
==28624== by 0x5036FAA: handler_hook (mod_xml_rpc.c:777)
==28624==
==28624==
==28624== 3,687,864 (3,687,790 direct, 74 indirect) bytes in 99,670
blocks are definitely lost in loss record 523 of 529
==28624== at 0x4022AB8: malloc (vg_replace_malloc.c:207)
==28624== by 0x444AFCF: strdup (in /lib/tls/i686/cmov/libc-2.7.so)
==28624== by 0x40E4EA9: switch_log_vprintf (switch_log.c:438)
==28624== by 0x40E5130: switch_log_printf (switch_log.c:308)
==28624== by 0x408A4B7: switch_channel_perform_mark_answered
(switch_channel.c:1914)
==28624== by 0x50B8528: sofia_event_callback (sofia.c:3807)
==28624== by 0x5146787: nua_application_event (nua_stack.c:393)
==28624== by 0x519DB28: su_base_port_execute_msgs (su_base_port.c:280)
==28624== by 0x519D8CF: su_base_port_getmsgs (su_base_port.c:202)
==28624== by 0x519DE27: su_base_port_step (su_base_port.c:473)
==28624== by 0x5190968: su_port_step (su_port.h:340)
==28624== by 0x5190938: su_root_step (su_root.c:858)
==28624==
==28624==
==28624== 4,833,280 bytes in 590 blocks are still reachable in loss
record 524 of 529
==28624== at 0x4022AB8: malloc (vg_replace_malloc.c:207)
==28624== by 0x410C0EC: apr_palloc (apr_pools.c:300)
==28624== by 0x41112CF: apr_threadattr_create (thread.c:45)
==28624== by 0x4080953: switch_threadattr_create (switch_apr.c:589)
==28624== by 0x6C27891: lua_thread (mod_lua.cpp:369)
==28624== by 0x6C27948: ??? (mod_lua.cpp:407)
==28624== by 0x40AADFC: switch_api_execute (switch_loadable_module.c:1567)
==28624== by 0x583A7FC: ??? (mod_commands.c:2426)
==28624== by 0x40A8881: switch_scheduler_execute (switch_scheduler.c:61)
==28624== by 0x40A8DE0: task_thread_loop (switch_scheduler.c:127)
==28624== by 0x40A8EA3: switch_scheduler_task_thread (switch_scheduler.c:168)
==28624== by 0x4110E05: dummy_worker (thread.c:138)
==28624==
==28624==
==28624== 6,502,484 (6,502,269 direct, 215 indirect) bytes in 175,737
blocks are definitely lost in loss record 525 of 529
==28624== at 0x4022AB8: malloc (vg_replace_malloc.c:207)
==28624== by 0x444AFCF: strdup (in /lib/tls/i686/cmov/libc-2.7.so)
==28624== by 0x40E4EA9: switch_log_vprintf (switch_log.c:438)
==28624== by 0x40E5130: switch_log_printf (switch_log.c:308)
==28624== by 0x409921F: switch_core_session_perform_destroy
(switch_core_session.c:947)
==28624== by 0x409A60D: switch_core_session_thread
(switch_core_session.c:1088)
==28624== by 0x4110E05: dummy_worker (thread.c:138)
==28624== by 0x42114FA: start_thread (in
/lib/tls/i686/cmov/libpthread-2.7.so)
==28624== by 0x44AFE5D: clone (in /lib/tls/i686/cmov/libc-2.7.so)
==28624==
==28624==
==28624== 6,515,323 (6,515,219 direct, 104 indirect) bytes in 176,087
blocks are definitely lost in loss record 526 of 529
==28624== at 0x4022AB8: malloc (vg_replace_malloc.c:207)
==28624== by 0x444AFCF: strdup (in /lib/tls/i686/cmov/libc-2.7.so)
==28624== by 0x40E4EA9: switch_log_vprintf (switch_log.c:438)
==28624== by 0x40E5130: switch_log_printf (switch_log.c:308)
==28624== by 0x409A5EC: switch_core_session_thread
(switch_core_session.c:1086)
==28624== by 0x4110E05: dummy_worker (thread.c:138)
==28624== by 0x42114FA: start_thread (in
/lib/tls/i686/cmov/libpthread-2.7.so)
==28624== by 0x44AFE5D: clone (in /lib/tls/i686/cmov/libc-2.7.so)
==28624==
==28624==
==28624== 7,557,720 bytes in 251,924 blocks are definitely lost in
loss record 527 of 529
==28624== at 0x4022AB8: malloc (vg_replace_malloc.c:207)
==28624== by 0x443B957: vasprintf (in /lib/tls/i686/cmov/libc-2.7.so)
==28624== by 0x5038532: xmlrpc_vasprintf (asprintf.c:61)
==28624== by 0x5038581: xmlrpc_asprintf (asprintf.c:81)
==28624== by 0x503B881: DateToString (date.c:43)
==28624== by 0x5036D09: handler_hook (mod_xml_rpc.c:733)
==28624== by 0x504456F: ??? (server.c:515)
==28624== by 0x5039FAF: ??? (conn.c:37)
==28624== by 0x50486F1: ??? (thread_pthread.c:4Cool
==28624== by 0x42114FA: start_thread (in
/lib/tls/i686/cmov/libpthread-2.7.so)
==28624== by 0x44AFE5D: clone (in /lib/tls/i686/cmov/libc-2.7.so)
==28624==
==28624==
==28624== 8,700,546 (8,700,436 direct, 110 indirect) bytes in 253,570
blocks are definitely lost in loss record 528 of 529
==28624== at 0x4022AB8: malloc (vg_replace_malloc.c:207)
==28624== by 0x444AFCF: strdup (in /lib/tls/i686/cmov/libc-2.7.so)
==28624== by 0x50384F2: xmlrpc_strdupnull (asprintf.c:92)
==28624== by 0x503F86D: RequestRead (http.c:57)
==28624== by 0x5044413: ??? (server.c:538)
==28624== by 0x5039FAF: ??? (conn.c:37)
==28624== by 0x50486F1: ??? (thread_pthread.c:4Cool
==28624== by 0x42114FA: start_thread (in
/lib/tls/i686/cmov/libpthread-2.7.so)
==28624== by 0x44AFE5D: clone (in /lib/tls/i686/cmov/libc-2.7.so)
==28624==
==28624==
==28624== 672,268,288 bytes in 82,064 blocks are still reachable in
loss record 529 of 529
==28624== at 0x4022AB8: malloc (vg_replace_malloc.c:207)
==28624== by 0x410BB2F: apr_pool_create_ex (apr_pools.c:300)
==28624== by 0x4111176: apr_thread_create (thread.c:171)
==28624== by 0x4080878: switch_thread_create (switch_apr.c:631)
==28624== by 0x6C278E9: lua_thread (mod_lua.cpp:372)
==28624== by 0x6C27948: ??? (mod_lua.cpp:407)
==28624== by 0x40AADFC: switch_api_execute (switch_loadable_module.c:1567)
==28624== by 0x583A7FC: ??? (mod_commands.c:2426)
==28624== by 0x40A8881: switch_scheduler_execute (switch_scheduler.c:61)
==28624== by 0x40A8DE0: task_thread_loop (switch_scheduler.c:127)
==28624== by 0x40A8EA3: switch_scheduler_task_thread (switch_scheduler.c:168)
==28624== by 0x4110E05: dummy_worker (thread.c:138)
==28624==
==28624== LEAK SUMMARY:
==28624== definitely lost: 63,113,740 bytes in 1,690,880 blocks.
==28624== indirectly lost: 35,632 bytes in 491 blocks.
==28624== possibly lost: 645,758 bytes in 9,150 blocks.
==28624== still reachable: 681,849,684 bytes in 113,077 blocks.
==28624== suppressed: 0 bytes in 0 blocks.


On Fri, Sep 4, 2009 at 7:42 AM, Benedikt
Fraunhofer<fraunhofer.lists.freeswitch-001@traced.net> wrote:
Quote:
Hello Anthony,

2009/9/2 Anthony Minessale <anthony.minessale@gmail.com>:

Quote:
yes if you have a version that only has log-file you can use that.

if you find me on irc and send me the credentials privately I will examine
your box for you.

thanks for that offer, but the box is pretty deep inside our internal
network with no routing to the outside, several stepping-stones in
between and all that "security" stuff.

I finally found the right amount of load where the memory leak builds
up quickly enough and was able to stop freeswitch before it started
swapping. The result is available on

 http://ns42.ath.cx/B0GdWh/vg-2.log.bz2

(19k)

Thx in advance
 Beni.

_______________________________________________
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

_______________________________________________
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
Back to top
rupa at rupa.com
Guest





PostPosted: Fri Sep 04, 2009 9:39 am    Post subject: [Freeswitch-users] memory leak Reply with quote

Doesn't that look like a pool that isn't being destroyed?

On Fri, Sep 4, 2009 at 9:10 AM, Rupa Schomaker<rupa@rupa.com> wrote:
Quote:
Worst offenders (leakers over 100K).  The last one is the worst (672M)
-- looks like a lua script.  What are you doing in lua again?
==28624== 672,268,288 bytes in 82,064 blocks are still reachable in
loss record 529 of 529
==28624==    at 0x4022AB8: malloc (vg_replace_malloc.c:207)
==28624==    by 0x410BB2F: apr_pool_create_ex (apr_pools.c:300)
==28624==    by 0x4111176: apr_thread_create (thread.c:171)
==28624==    by 0x4080878: switch_thread_create (switch_apr.c:631)
==28624==    by 0x6C278E9: lua_thread (mod_lua.cpp:372)
==28624==    by 0x6C27948: ??? (mod_lua.cpp:407)
==28624==    by 0x40AADFC: switch_api_execute (switch_loadable_module.c:1567)
==28624==    by 0x583A7FC: ??? (mod_commands.c:2426)
==28624==    by 0x40A8881: switch_scheduler_execute (switch_scheduler.c:61)
==28624==    by 0x40A8DE0: task_thread_loop (switch_scheduler.c:127)
==28624==    by 0x40A8EA3: switch_scheduler_task_thread (switch_scheduler.c:168)
==28624==    by 0x4110E05: dummy_worker (thread.c:138)
==28624==
==28624== LEAK SUMMARY:
==28624==    definitely lost: 63,113,740 bytes in 1,690,880 blocks.
==28624==    indirectly lost: 35,632 bytes in 491 blocks.
==28624==      possibly lost: 645,758 bytes in 9,150 blocks.
==28624==    still reachable: 681,849,684 bytes in 113,077 blocks.
==28624==         suppressed: 0 bytes in 0 blocks.

--
-Rupa

_______________________________________________
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
Back to top
fraunhofer.lists.frees...
Guest





PostPosted: Fri Sep 04, 2009 9:44 am    Post subject: [Freeswitch-users] memory leak Reply with quote

2009/9/4 Rupa Schomaker <rupa@rupa.com>:
Quote:
Worst offenders (leakers over 100K).  The last one is the worst (672M)
-- looks like a lua script.  What are you doing in lua again?

i feel kinda dumb to double post, but here it is again :)

the setup is the same as in http://jira.freeswitch.org/browse/MODSOFIA-22

one is

-----

local reason = session:getVariable("originate_disposition");

session:setAutoHangup(false);


if(reason) then
if(reason == "NO_ANSWER") then
-- nothing
end
if(reason == "USER_BUSY") then
-- nothing
end
end

freeswitch.consoleLog(...

------
anotherone is
----
local sess = "nil";
if(argv[1]) then
sess=argv[1];
end
freeswitch.consoleLog(...
api = freeswitch.API();
local res = api:execute("sched_api" ...
freeswitch.consoleLog(...

----

and the scheduled script does
---
function log(msg)
freeswitch.consoleLog("notice", "c2c-hangup-timeout.lua: " .. msg .. "\n");
end


local sess = argv[1];
if(sess)
then
freeswitch.consoleLog("INFO", "hangup-timeout.lua for uuid " ..
sess .. "\n");

api = freeswitch.API();
local stillValid = api:execute("uuid_getvar", sess .. "
Dummy-DoesChannelExists");
if(stillValid:sub(1,4) == "-ERR")
then
log("session uuid " .. sess .. " disappeared (nothing bad)");
else
-- this is important!!! Otherwise the aleg get's just hung up!
api:execute("uuid_media", sess);
api:execute("uuid_transfer", sess .. " -both timeout");
end
else -- /if(sess)
log("called with nil session?");
end -- /if(sess)

---

at least there's no fancy db-connection-thingi which could make
debugging harder :)

Cheers
Beni.

_______________________________________________
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
Back to top
fraunhofer.lists.frees...
Guest





PostPosted: Fri Sep 04, 2009 9:49 am    Post subject: [Freeswitch-users] memory leak Reply with quote

personally i would blame xmlrpc (which is no xml Smile for it.

Just my 2cent

Beni.

_______________________________________________
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
Back to top
rupa at rupa.com
Guest





PostPosted: Fri Sep 04, 2009 9:52 am    Post subject: [Freeswitch-users] memory leak Reply with quote

There are other smaller leakers. xmlrpc is leaking, but the leaks are
very small compared to the lua leak. Same with spidermonkey_curl - it
is leaking but not too terribly much. I'll hop on #freeswitch in a
bit and see if anyone has an idea.

On Fri, Sep 4, 2009 at 9:35 AM, Benedikt
Fraunhofer<fraunhofer.lists.freeswitch-001@traced.net> wrote:
Quote:
personally i would blame xmlrpc (which is no xml Smile for it.

Just my 2cent

 Beni.

Quote:
http://www.freeswitch.org




--
-Rupa

_______________________________________________
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
Back to top
anthony.minessale at g...
Guest





PostPosted: Fri Sep 04, 2009 10:14 am    Post subject: [Freeswitch-users] memory leak Reply with quote

that looks to me like luarun being called on a script that never terminates.
could your script be ending up caught in an endless loop or blocking on something?


On Fri, Sep 4, 2009 at 9:42 AM, Rupa Schomaker <rupa@rupa.com (rupa@rupa.com)> wrote:
Quote:
There are other smaller leakers.  xmlrpc is leaking, but the leaks are
very small compared to the lua leak.  Same with spidermonkey_curl - it
is leaking but not too terribly much.  I'll hop on #freeswitch in a
bit and see if anyone has an idea.

On Fri, Sep 4, 2009 at 9:35 AM, Benedikt
Fraunhofer<fraunhofer.lists.freeswitch-001@traced.net (fraunhofer.lists.freeswitch-001@traced.net)> wrote:

Quote:
personally i would blame xmlrpc (which is no xml Smile for it.

Just my 2cent

 Beni.


Quote:
http://www.freeswitch.org




--
-Rupa

_______________________________________________


FreeSWITCH-users mailing list
FreeSWITCH-users@lists.freeswitch.org (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 ([email]MSN%3Aanthony_minessale@hotmail.com[/email])
GTALK/JABBER/PAYPAL:anthony.minessale@gmail.com ([email]PAYPAL%3Aanthony.minessale@gmail.com[/email])
IRC: irc.freenode.net #freeswitch

FreeSWITCH Developer Conference
sip:888@conference.freeswitch.org ([email]sip%3A888@conference.freeswitch.org[/email])
iax:guest@conference.freeswitch.org/888
googletalk:conf+888@conference.freeswitch.org ([email]googletalk%3Aconf%2B888@conference.freeswitch.org[/email])
pstn:213-799-1400
Back to top
fraunhofer.lists.frees...
Guest





PostPosted: Wed Sep 09, 2009 5:05 am    Post subject: [Freeswitch-users] memory leak Reply with quote

Hello *,

the latest bugfixes for luarun (pool allocation) fixed it.
It's working now with luarun (friday-monday) and bgapi (monday-today).
The last test with the new "&" operator for sched_api is currently running.

Thx!

Beni.

_______________________________________________
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
Back to top
rupa at rupa.com
Guest





PostPosted: Wed Sep 09, 2009 9:50 am    Post subject: [Freeswitch-users] memory leak Reply with quote

On Wed, Sep 9, 2009 at 4:58 AM, Benedikt
Fraunhofer<fraunhofer.lists.freeswitch-001@traced.net> wrote:
Quote:
Hello *,

the latest bugfixes for luarun (pool allocation) fixed it.
It's working now with luarun (friday-monday) and bgapi (monday-today).
The last test with the new "&" operator for sched_api is currently running.

Thx!

 Beni.

Great news! Another one bites the dust. Smile

--
-Rupa

_______________________________________________
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
Back to top
fraunhofer.lists.frees...
Guest





PostPosted: Fri Sep 11, 2009 2:37 am    Post subject: [Freeswitch-users] memory leak Reply with quote

Hello *,

"sched_api ... &"

works, too.

Thx again and looking forward to the next bug Smile

Beni.

_______________________________________________
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
Back to top
brian at freeswitch.org
Guest





PostPosted: Fri Sep 11, 2009 8:26 am    Post subject: [Freeswitch-users] memory leak Reply with quote

Next Bug? Huh? Razz

/b

On Sep 11, 2009, at 2:32 AM, Benedikt Fraunhofer wrote:

Quote:

Thx again and looking forward to the next bug Smile


_______________________________________________
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
Back to top
Display posts from previous:   
Post new topic   Reply to topic    VoIP Mailing List Archives Forum Index -> freeSWITCH Users All times are GMT - 5 Hours
Goto page Previous  1, 2
Page 2 of 2

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum


Powered by phpBB © 2001, 2005 phpBB Group

VoiceMeUp - Corporate & Wholesale VoIP Services