9 Jun
2009
9 Jun
'09
9:38 a.m.
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:
_______________________________________________
Kamailio (OpenSER) - Users mailing list
Users(a)lists.kamailio.org
http://lists.kamailio.org/cgi-bin/mailman/listinfo/users
http://lists.openser-project.org/cgi-bin/mailman/listinfo/users 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@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