[Kamailio-Users] freeing innername from htable Re: perl module, "pv_sprintf: Memory exhausted!"
Christian Koch
chri.koch.vier at googlemail.com
Tue Jun 9 09:38:30 CEST 2009
Hello again,
as no one answered our question yet, we would like to ask again if
someone is maybe able to take a deeper look in this?
We are really stuck here and will also post this issue again on the
devel list, maybe someone there is also able to take a look into this.
Any help is really appreciated.
Thanks and regards,
Christian Koch
Christian Koch schrieb:
> Hi Henning, hi Daniel,
>
> we did some more investigation and now we think, the problem may occur
> when accessing the "inner name" of pv's from htable.
>
> We included a call to backtrace() in pv_parse_ht_name() (where most of
> the memory was allocated) to find out, which calling function would be
> responsible for freeing the allocated memory. First we thought it
> could be xlog, but more tests showed, the error also occurs when
> called from other modules.
> pv_parse_ht_name() is set as the innername in the htable module:
>
> static pv_export_t mod_pvs[] = {
> { {"sht", sizeof("sht")-1}, PVT_OTHER, pv_get_ht_cell, pv_set_ht_cell,
> pv_parse_ht_name, 0, 0, 0 },
>
> pv_parse_ht_name() allocates some memory (line 121, ht_var.c), saves
> it in sp->pvp.pvn.u.dname (line 165) and sets the type to
> PV_NAME_PVAR. As "u" is a union we thought freeing the memory should
> depend on the type. We can not find any place, where type is checked
> for PV_NAME_PVAR and any memory is freed.
>
> Could you give us any hints where this should happen? Maybe this is
> the only thing we have to add and the memory leak is gone.
>
> By the way, when searching for PV_NAME_INTSTR we found a potential
> bug: In pvapi.c there is the follwoing piece of code (line 773 to 785):
>
> if(ip->pvn.type==PV_NAME_INTSTR)
> {
> [...]
> } else if(ip->pvn.type==PV_NAME_INTSTR) {
> /* pvar */
>
> The second if also checks for PV_NAME_INTSTR so it will never be
> executed. Shouldn't this be PV_NAME_PVAR?
>
> Regards,
> Christian
>
>
>
> Christian Koch schrieb:
>> Hi Henning,
>>
>> Henning Westerholt schrieb:
>>> Can you configure the kamailio server that it generates a core file?
>>> Then take a look to the backtrace where the invalid memory access
>>> was done, to verify if its really crashed in the core function, or
>>> perhaps some other parts has a problem here. Further informations:
>>> http://www.kamailio.org/dokuwiki/doku.php/troubleshooting:corefiles
>>>
>>>
>> We generated a core file, the output of the backtrace is:
>>
>> (gdb) bt
>> #0 0x00b237a2 in _dl_sysinfo_int80 () from /lib/ld-linux.so.2
>> #1 0x00b64825 in raise () from /lib/tls/libc.so.6
>> #2 0x00b66289 in abort () from /lib/tls/libc.so.6
>> #3 0x080c4436 in qm_free (qm=0x81677e0, p=0x0, file=0x811728e
>> "proxy.c", func=0x811724e "hostent_cpy", line=187) at mem/q_malloc.c:444
>> #4 0x0807e329 in hostent_cpy (dst=0x8266e28, src=0x8146134) at
>> proxy.c:187
>> #5 0x0807ea16 in mk_proxy (name=0xbfe8f380, port=0, proto=0,
>> is_sips=0) at proxy.c:305
>> #6 0x0023cf81 in add_uac (t=0xb61d6128, request=0x81bb218,
>> uri=0xbfe8f538, next_hop=0xbfe8f540, path=0x81bb538, proxy=0x0) at
>> ut.h:67
>> #7 0x0023e74c in t_forward_nonack (t=0xb61d6128, p_msg=0x81bb218,
>> proxy=0x0) at t_fwd.c:630
>> #8 0x0023a501 in t_relay_to (p_msg=0x81bb218, proxy=0x0,
>> flags=Variable "flags" is not available.
>> ) at t_funcs.c:264
>> #9 0x0024eb9f in w_t_relay (p_msg=0x81bb218, proxy=0x0, flags=0x0)
>> at tm.c:1002
>> #10 0x080531ed in do_action (a=0x81a966c, msg=0x81bb218) at action.c:874
>> #11 0x08055406 in run_action_list (a=0x81a966c, msg=0x81bb218) at
>> action.c:145
>> #12 0x08094fb0 in eval_expr (e=0x81a96fc, msg=0x81bb218, val=0x0) at
>> route.c:1171
>> #13 0x08095214 in eval_expr (e=0x81a974c, msg=0x81bb218, val=0x0) at
>> route.c:1488
>> #14 0x08094b6f in eval_expr (e=0x81a979c, msg=0x81bb218, val=0x0) at
>> route.c:1493
>> #15 0x080526d8 in do_action (a=0x81a9d7c, msg=0x81bb218) at action.c:729
>> #16 0x08055406 in run_action_list (a=0x81a952c, msg=0x81bb218) at
>> action.c:145
>> #17 0x08053ed9 in do_action (a=0x81a7efc, msg=0x81bb218) at action.c:120
>> #18 0x08055406 in run_action_list (a=0x81a7efc, msg=0x81bb218) at
>> action.c:145
>> #19 0x08054f85 in do_action (a=0x81a86ac, msg=0x81bb218) at action.c:746
>> #20 0x08055406 in run_action_list (a=0x81a86ac, msg=0x81bb218) at
>> action.c:145
>> #21 0x08054fbc in do_action (a=0x81a873c, msg=0x81bb218) at action.c:752
>> #22 0x08055406 in run_action_list (a=0x81a246c, msg=0x81bb218) at
>> action.c:145
>> #23 0x0805570e in run_top_route (a=0x81a246c, msg=0x81bb218) at
>> action.c:120
>> #24 0x08087994 in receive_msg (
>> buf=0x8146ba0 "CANCEL sip:1001 at 212.59.42.187
>> SIP/2.0\r\nRecord-Route:
>> <sip:212.59.42.187;lr=on;ftag=ACU-6afbe8bb-f11cd9dc>\r\nRecord-Route:
>> <sip:212.59.42.187;lr=on;ftag=ACU-6afbe8bb-f11cd9dc>\r\nRecord-Route:
>> <sip:212.59"..., len=1499, rcv_info=0xbfe91240) at receive.c:175
>> #25 0x080be606 in udp_rcv_loop () at udp_server.c:449
>> #26 0x0806b361 in main (argc=3, argv=0xbfe914b4) at main.c:774
>>
>> This core file obviuosly only occurs, because there is no more pkg
>> memory. proxy.c:
>>
>> dst->h_addr_list=(char**)pkg_malloc(sizeof(char*)*(len+1));
>> if (dst->h_addr_list==0){
>> ser_error=ret=E_OUT_OF_MEM;
>> pkg_free(dst->h_name);
>> for(r=0; dst->h_aliases[r]; r++)
>> pkg_free(dst->h_aliases[r]);
>> pkg_free(dst->h_aliases[r]); <-- THIS IS LINE 187,
>> WHERE THE CORE FILE IS GENERATED
>> pkg_free(dst->h_aliases);
>> goto error;
>> }
>>
>> So, there may be an error in proxy.c, but perhaps the reason for our
>> problem is in modules/htable/ht_var.c in pv_parse_ht_name(), where
>> the variable hpv is not freed?
>> Any comments on pv_parse_ht_name() are greatly appreciated. We could
>> try to fix this, but we're not sure about the sideeffects.
>>
>> Regards,
>> Christian
>>
>
>
> _______________________________________________
> Kamailio (OpenSER) - Users mailing list
> Users at lists.kamailio.org
> http://lists.kamailio.org/cgi-bin/mailman/listinfo/users
> http://lists.openser-project.org/cgi-bin/mailman/listinfo/users
More information about the sr-users
mailing list