[Kamailio-Users] freeing innername from htable Re: perl module, "pv_sprintf: Memory exhausted!"

Daniel-Constantin Mierla miconda at gmail.com
Tue Jun 9 09:41:50 CEST 2009


Hello Christian,

I got your email but I was out in a short vacation. I will check it.

Thanks,
Daniel


On 06/09/2009 10:38 AM, Christian Koch wrote:
> 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
>
>
> _______________________________________________
> 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
>

-- 
Daniel-Constantin Mierla
http://www.asipto.com/





More information about the sr-users mailing list