[Kamailio-Users] freeing innername from htable Re: perl module, "pv_sprintf: Memory exhausted!"
Daniel-Constantin Mierla
miconda at gmail.com
Tue Jun 9 11:13:03 CEST 2009
Hello,
On 06/03/2009 03:01 PM, Christian Koch wrote:
> 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.
Do you call pv_parse_ht_name() from perl? If not, that function is
executed only at startup and it is not a cause for leaking. A clean
shutdown should free it, but there is not complete support for it (some
fixup functions have a free function, others done, as well as the script
actions tree).
That structure is not freed because it used at runtime. During startup,
the name of $sht is parsed and kept as custom structure to be used
latter, for speed reasons.
I tried to access the files you uploaded, with the log, but they
expired. If you have the one with memory debug, please send it to me.
>
> 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?
Yes, should have been so and it is now fixed. The issue was pretty
harmless, as that function was called mainly for avps and hdrs PV with
int or str name.
Thanks,
Daniel
>
> 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
>
--
Daniel-Constantin Mierla
http://www.asipto.com/
More information about the Users
mailing list