Hello, maybe you can send me a simple kamailio.cfg that exposes the issue, along with the details of how to reproduce.
Cheers, Daniel On 05/07/16 10:58, José Seabra wrote: > Hello Daniel, > Is there any possibility of you explain me what do you need from GDB > and I execute these steps in the server? > That's because create a new environment will take me lot of time, > > If it isn't possible, I will create the new environment. > > Thank you for your help. > Regards > José > > > 2016-07-04 17:59 GMT+01:00 José Seabra <joseseab...@gmail.com > <mailto:joseseab...@gmail.com>>: > > Hello, > > It won't be ease because of the network firewall where the servers > are behind. > > I will setup a new test environment in my laptop then give feedback. > > Regards > José > > 2016-07-04 15:46 GMT+01:00 Daniel-Constantin Mierla > <mico...@gmail.com <mailto:mico...@gmail.com>>: > > 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: >> Hello >> >> I'm using lookup() and registered(). >> >> Let me know if do you need more information or tests from my >> side. >> >> Regards >> >> 2016-07-04 14:41 GMT+01:00 Daniel-Constantin Mierla >> <mico...@gmail.com <mailto:mico...@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: >>> 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") >>> >>> Let me know if do you need more information. >>> >>> Regards >>> José >>> >>> 2016-07-04 13:20 GMT+01:00 Daniel-Constantin Mierla >>> <mico...@gmail.com <mailto:mico...@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: >>>> Hello Daniel, >>>> >>>> I think that the issue is on registrar module. >>>> >>>> I'm using the following parameters: >>>> >>>> * modparam("registrar", "xavp_cfg", "regcfg") >>>> * modparam("registrar", "xavp_rcd", "ulrcd") >>>> >>>> If I disable it there isn't memory leak. >>>> >>>> Let me know if you need more information. >>>> >>>> Thank you >>>> Regards >>>> José >>>> >>>> 2016-07-04 11:27 GMT+01:00 Daniel-Constantin Mierla >>>> <mico...@gmail.com <mailto:mico...@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. >>>>> Regards >>>>> José >>>>> >>>> >>>> >>>> -- >>>> Daniel-Constantin Mierla >>>> http://www.asipto.com - http://www.kamailio.org >>>> http://twitter.com/#!/miconda >>>> <http://twitter.com/#%21/miconda> - >>>> http://www.linkedin.com/in/miconda >>>> >>>> >>>> _______________________________________________ >>>> SIP Express Router (SER) and Kamailio (OpenSER) >>>> - sr-users mailing list >>>> sr-users@lists.sip-router.org >>>> <mailto:sr-users@lists.sip-router.org> >>>> >>>> http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users >>>> >>>> >>>> >>>> >>>> -- >>>> Cumprimentos >>>> José Seabra >>> >>> -- >>> Daniel-Constantin Mierla >>> http://www.asipto.com - http://www.kamailio.org >>> http://twitter.com/#!/miconda >>> <http://twitter.com/#%21/miconda> - >>> http://www.linkedin.com/in/miconda >>> >>> >>> >>> >>> -- >>> Cumprimentos >>> José Seabra >> >> -- >> Daniel-Constantin Mierla >> http://www.asipto.com - http://www.kamailio.org >> http://twitter.com/#!/miconda >> <http://twitter.com/#%21/miconda> - >> http://www.linkedin.com/in/miconda >> >> >> >> >> -- >> Cumprimentos >> José Seabra > > -- > Daniel-Constantin Mierla > http://www.asipto.com - http://www.kamailio.org > http://twitter.com/#!/miconda <http://twitter.com/#%21/miconda> - > http://www.linkedin.com/in/miconda > > > > > -- > Cumprimentos > José Seabra > > > > > -- > Cumprimentos > José Seabra -- 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
