Hello,
looking at the source code, it seems that the xavp is linked to the root list and should be deleted with the rest of xavps when the message/transaction structure is destroyed.
Would it be possible to allow me access to the test system in order to check the memory of kamailio with gdb?
Cheers,
Daniel
On 04/07/16 15:48, José Seabra wrote:
RegardsHelloLet me know if do you need more information or tests from my side.
I'm using lookup() and registered().
2016-07-04 14:41 GMT+01:00 Daniel-Constantin Mierla <miconda@gmail.com>:
Hello,
one more question: are you using only lookup(...) or using registered(...) (or other functions from registrar module) as well?
Cheers,
Daniel
On 04/07/16 15:21, José Seabra wrote:
JoséRegardsLet me know if do you need more information.Hello,Right now I'm using registrar functions only in request_route.
At first i had disabled both, after received your email, I disabled one by one and I see that the only the parameter that is affecting this, is modparam("registrar", "xavp_rcd", "ulrcd")
2016-07-04 13:20 GMT+01:00 Daniel-Constantin Mierla <miconda@gmail.com>:
Hello,
very useful information -- are you using the registrar functions only inside request_route, or you have them also in failure_route or other type of routes?
Were you able to detect if both cause the leak or you disabled both of them without trying each one?
Cheers,
Daniel
On 04/07/16 14:01, José Seabra wrote:
JoséRegardsThank youLet me know if you need more information.If I disable it there isn't memory leak.I'm using the following parameters:Hello Daniel,I think that the issue is on registrar module.
- modparam("registrar", "xavp_cfg", "regcfg")
- modparam("registrar", "xavp_rcd", "ulrcd")
2016-07-04 11:27 GMT+01:00 Daniel-Constantin Mierla <miconda@gmail.com>:
Hello,
can you provide more details about where you use xavps in the configuration file? Do you use them in some route block executed by rtimer or via asyn framework (e.g., via t_continue() or async module)?
Cheers,
Daniel
On 03/07/16 20:35, José Seabra wrote:
Hello,I'm monitoring these testes with "corex.shm_summary" provided by kamcmd.
I'm noticing that the core module - xavp.c is consuming lot of memory and it is increasing.
result of command corex.shm_summary is:
fm_status: summarizing all alloc'ed. fragments:fm_status: count= 2 size= 1120 bytes from tm: t_reply.c: _reply_light(542)fm_status: count= 2 size= 896 bytes from tm: t_msgbuilder.c: build_uac_req(1543)fm_status: count= 2182 size= 231088 bytes from tm: t_fwd.c: prepare_new_uac(479)fm_status: count= 12488 size= 12050808 bytes from tm: t_reply.c: relay_reply(1884)fm_status: count= 12490 size= 14564656 bytes from core: msg_translator.c: build_req_buf_from_sip_req(2149)fm_status: count= 12492 size= 71366536 bytes from tm: h_table.c: build_cell(317)fm_status: count= 12490 size= 75086184 bytes from core: sip_msg_clone.c: sip_msg_shm_clone(494)fm_status: count= 2 size= 96 bytes from tm: t_hooks.c: insert_tmcb(137)fm_status: count= 2182 size= 17800 bytes from tm: t_fwd.c: prepare_new_uac(524)fm_status: count= 3 size= 512 bytes from htable: ht_api.c: ht_cell_new(183)fm_status: count= 12490 size= 10586712 bytes from core: sip_msg_clone.c: msg_lump_cloner(978)fm_status: count= 56508 size= 3457904 bytes from core: usr_avp.c: create_avp(175)fm_status: count= 4 size= 600 bytes from tmx: tmx_pretran.c: tmx_check_pretran(250)fm_status: count= 4 size= 1008 bytes from usrloc: ucontact.c: new_ucontact(98)fm_status: count= 4 size= 1320 bytes from tmx: tmx_pretran.c: tmx_check_pretran(271)fm_status: count= 4 size= 144 bytes from usrloc: urecord.c: new_urecord(65)fm_status: count= 4 size= 328 bytes from usrloc: urecord.c: new_urecord(58)fm_status: count= 24 size= 952 bytes from usrloc: ../../ut.h: shm_str_dup(723)fm_status: count= 2182 size= 53040 bytes from tm: t_fwd.c: prepare_new_uac(509)fm_status: count=12545409 size=1420184592 bytes from core: xavp.c: xavp_new_value(94)fm_status: count= 4 size= 128 bytes from dmq: worker.c: alloc_job_queue(229)fm_status: count= 1 size= 13440 bytes from core: counters.c: counters_prefork_init(207)fm_status: count= 1 size= 4032 bytes from sl: sl_stats.c: init_sl_stats_child(125)fm_status: count= 1 size= 256 bytes from tmx: tmx_pretran.c: tmx_init_pretran_table(90)fm_status: count= 1 size= 5376 bytes from tm: t_stats.c: init_tm_stats_child(60)fm_status: count= 1 size= 1008 bytes from kex: pkg_stats.c: pkg_proc_stats_init(79)fm_status: count= 3 size= 88 bytes from core: cfg/cfg_struct.c: cfg_clone_str(130)fm_status: count= 1 size= 744 bytes from core: cfg/cfg_struct.c: cfg_shmize(217)fm_status: count= 3 size= 64 bytes from usrloc: udomain.c: build_stat_name(51)fm_status: count= 1 size= 40960 bytes from usrloc: udomain.c: new_udomain(93)fm_status: count= 1 size= 48 bytes from usrloc: udomain.c: new_udomain(86)fm_status: count= 1 size= 16 bytes from usrloc: dlist.c: new_dlist(573)fm_status: count= 1 size= 32 bytes from usrloc: dlist.c: new_dlist(565)fm_status: count= 1 size= 8 bytes from core: pt.c: init_pt(110)fm_status: count= 1 size= 8 bytes from core: pt.c: init_pt(105)fm_status: count= 1 size= 2944 bytes from core: pt.c: init_pt(104)fm_status: count= 1 size= 32 bytes from usrloc: ul_callback.c: register_ulcb(94)fm_status: count= 1 size= 24 bytes from dmq: ../../ut.h: shm_str_dup(723)fm_status: count= 1 size= 448 bytes from dmq: dmqnode.c: build_dmq_node(156)fm_status: count= 2 size= 168 bytes from dmq: peer.c: add_peer(67)fm_status: count= 1 size= 8 bytes from dmq: dmq.c: mod_init(243)fm_status: count= 1 size= 96 bytes from dmq: dmq.c: mod_init(237)fm_status: count= 1 size= 24 bytes from dmq: dmqnode.c: init_dmq_node_list(66)fm_status: count= 1 size= 24 bytes from dmq: peer.c: init_peer_list(33)fm_status: count= 1 size= 16 bytes from usrloc: ul_callback.c: init_ulcb_list(45)fm_status: count= 1 size= 4112 bytes from usrloc: ../../lock_alloc.h: lock_set_alloc(70)fm_status: count= 1 size= 8 bytes from carrierroute: cr_data.c: rule_fixup_recursor(584)fm_status: count= 5 size= 56 bytes from carrierroute: ../../ut.h: shm_str_dup(723)fm_status: count= 1 size= 152 bytes from carrierroute: cr_rule.c: add_route_rule(74)fm_status: count= 3 size= 240 bytes from core: dtrie.c: dtrie_insert(157)fm_status: count= 3 size= 48 bytes from core: dtrie.c: dtrie_insert(148)fm_status: count= 1 size= 48 bytes from carrierroute: cr_rule.c: add_route_flags(225)fm_status: count= 2 size= 160 bytes from core: dtrie.c: dtrie_init(60)fm_status: count= 2 size= 32 bytes from core: dtrie.c: dtrie_init(51)fm_status: count= 1 size= 32 bytes from carrierroute: cr_domain.c: create_domain_data(83)fm_status: count= 1 size= 8 bytes from carrierroute: cr_carrier.c: create_carrier_data(59)fm_status: count= 1 size= 64 bytes from carrierroute: cr_carrier.c: create_carrier_data(50)fm_status: count= 1 size= 8 bytes from carrierroute: cr_db.c: load_route_data_db(295)fm_status: count= 5 size= 1008 bytes from dispatcher: dispatch.c: reindex_dests(600)fm_status: count= 1 size= 48 bytes from carrierroute: cr_db.c: load_domain_map(182)fm_status: count= 1 size= 24 bytes from carrierroute: cr_db.c: load_domain_map(171)fm_status: count= 1 size= 48 bytes from carrierroute: cr_db.c: load_carrier_map(126)fm_status: count= 1 size= 24 bytes from carrierroute: cr_db.c: load_carrier_map(115)fm_status: count= 7 size= 168 bytes from dispatcher: dispatch.c: add_dest2list(350)fm_status: count= 1 size= 64 bytes from carrierroute: cr_data.c: reload_route_data(172)fm_status: count= 1 size= 8 bytes from carrierroute: cr_data.c: init_route_data(74)fm_status: count= 5 size= 4200 bytes from dispatcher: dispatch.c: add_dest2list(324)fm_status: count= 1 size= 16 bytes from dispatcher: dispatch.c: init_data(204)fm_status: count= 1 size= 16 bytes from dispatcher: dispatch.c: init_data(195)fm_status: count= 1 size= 8 bytes from dispatcher: dispatcher.c: mod_init(309)fm_status: count= 1 size= 8 bytes from dispatcher: dispatcher.c: mod_init(307)fm_status: count= 1 size= 8 bytes from dispatcher: dispatch.c: ds_ping_active_init(102)fm_status: count= 1 size= 256 bytes from db_text: dbt_lib.c: dbt_init_cache(81)fm_status: count= 1 size= 8 bytes from db_text: dbt_lib.c: dbt_init_cache(69)fm_status: count= 1 size= 8 bytes from db_text: dbt_lib.c: dbt_init_cache(54)fm_status: count= 3 size= 288 bytes from core: timer.c: register_timer(1011)fm_status: count= 4 size= 8388608 bytes from htable: ht_api.c: ht_init_tables(381)fm_status: count= 1 size= 8 bytes from sl: sl_funcs.c: sl_startup(83)fm_status: count= 1 size= 8 bytes from sl: sl_stats.c: init_sl_stats(110)fm_status: count= 1 size= 16 bytes from tm: t_hooks.c: init_tmcb_lists(74)fm_status: count= 1 size= 16 bytes from tm: t_hooks.c: init_tmcb_lists(72)fm_status: count= 1 size= 2097152 bytes from tm: h_table.c: init_hash_table(467)fm_status: count= 2 size= 64 bytes from core: cfg/cfg_ctx.c: cfg_register_ctx(47)fm_status: count= 1 size= 80 bytes from db_postgres: ../../lock_alloc.h: lock_set_alloc(70)fm_status: count= 1 size= 8192 bytes from core: tcp_main.c: init_tcp(4635)fm_status: count= 1 size= 32768 bytes from core: tcp_main.c: init_tcp(4629)fm_status: count= 1 size= 8 bytes from core: tcp_main.c: init_tcp(4621)fm_status: count= 1 size= 8 bytes from core: tcp_main.c: init_tcp(4614)fm_status: count= 1 size= 8 bytes from core: tcp_main.c: init_tcp(4607)fm_status: count= 1 size= 8 bytes from core: tcp_main.c: init_tcp(4601)fm_status: count= 1 size= 8 bytes from core: tcp_main.c: init_tcp(4589)fm_status: count= 1 size= 8 bytes from core: usr_avp.c: init_avps(90)fm_status: count= 1 size= 8 bytes from core: usr_avp.c: init_avps(89)fm_status: count= 1 size= 16384 bytes from core: dst_blacklist.c: init_dst_blacklist(437)fm_status: count= 1 size= 8 bytes from core: dst_blacklist.c: init_dst_blacklist(430)fm_status: count= 2 size= 96 bytes from core: timer.c: timer_alloc(514)fm_status: count= 1 size= 8 bytes from core: dns_cache.c: init_dns_cache(366)fm_status: count= 1 size= 16384 bytes from core: dns_cache.c: init_dns_cache(358)fm_status: count= 1 size= 16 bytes from core: dns_cache.c: init_dns_cache(351)fm_status: count= 1 size= 8 bytes from core: dns_cache.c: init_dns_cache(345)fm_status: count= 1 size= 8 bytes from core: timer.c: init_timer(283)fm_status: count= 1 size= 16384 bytes from core: timer.c: init_timer(282)fm_status: count= 1 size= 8 bytes from core: timer.c: init_timer(281)fm_status: count= 1 size= 8 bytes from core: timer.c: init_timer(280)fm_status: count= 1 size= 8 bytes from core: timer.c: init_timer(269)fm_status: count= 1 size= 8 bytes from core: timer.c: init_timer(237)fm_status: count= 1 size= 278544 bytes from core: timer.c: init_timer(220)fm_status: count= 1 size= 8 bytes from core: timer.c: init_timer(219)fm_status: count= 1 size= 8 bytes from core: timer.c: init_timer(206)fm_status: count= 1 size= 64 bytes from core: cfg/cfg_struct.c: cfg_child_cb_new(830)fm_status: count= 1 size= 8 bytes from core: cfg/cfg_struct.c: sr_cfg_init(361)fm_status: count= 1 size= 8 bytes from core: cfg/cfg_struct.c: sr_cfg_init(354)fm_status: count= 1 size= 8 bytes from core: cfg/cfg_struct.c: sr_cfg_init(347)fm_status: count= 1 size= 8 bytes from core: cfg/cfg_struct.c: sr_cfg_init(335)fm_status: count= 1 size= 8 bytes from core: cfg/cfg_struct.c: sr_cfg_init(323)fm_status: count= 4 size= 928 bytes from htable: ht_api.c: ht_add_table(278)fm_status: count= 1 size= 8 bytes from core: mem/shm.c: shm_core_lock_init(153)fm_status: -----------------------------
If i stop these tests and after few minutes, run again the command "corex.shm_summary" the entry that contains the memory consume for xavp.c doesn't decrease.
It seems that there is a memory leak in this module xavp.c.
Thank you for your help.RegardsJosé
-- Daniel-Constantin Mierla http://www.asipto.com - http://www.kamailio.org http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
_______________________________________________
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users@lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
--
CumprimentosJosé Seabra
-- Daniel-Constantin Mierla http://www.asipto.com - http://www.kamailio.org http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
--
CumprimentosJosé Seabra
-- Daniel-Constantin Mierla http://www.asipto.com - http://www.kamailio.org http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
--
CumprimentosJosé Seabra
-- Daniel-Constantin Mierla http://www.asipto.com - http://www.kamailio.org http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda