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

[Christian Koch]

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
>