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