[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 Users mailing list