[sr-dev] Infinite loop in xavp linked list

[Waite, Hugh]

Hello,
I believe I have found a bug in the xavp code (or a module that manipulates them - most likely the usrloc "ulattrs" feature), but I don't understand some bits of the xavp structure.
FYI the code I am running isn't master, it's from branch 4.1 plus a backport of my ulattrs from DB patch (http://git.sip-router.org/cgi-bin/gitweb.cgi?p=kamailio;a=commit;h=22b559cb25c25b3801b1849a5da76a8ec937ef83).

Basically the linked list of xavp values links back to the top and creates an infinite loop when searching/inserting/deleting etc.
(gdb) bt
#0  0x0000000000544235 in xavp_get_internal (name=0x7fbac95d11f8, list=0x7fbaae036248, idx=0, prv=0x0) at xavp.c:267
#1  0x0000000000544325 in xavp_get_by_index (name=0x7fbac95d11f8, idx=0, start=0x7fbaae036248) at xavp.c:288
#2  0x00007fbac3316074 in pv_get_xavp (msg=0x7fbac961f958, param=0x7fbac95d1638, res=0x7fff99ae69d0) at pv_xavp.c:133
#3  0x00000000004995c8 in pv_get_spec_value (msg=0x7fbac961f958, sp=0x7fbac95d1620, value=0x7fff99ae69d0) at pvapi.c:1266
#4  0x00000000004c8c68 in rv_defined (h=0x7fff99ae72d0, msg=0x7fbac961f958, res=0x7fff99ae6fe8, rv=0x7fbac95d1618, cache=0x0) at rvalue.c:1859
#5  0x00000000004c8d1b in int_rve_defined (h=0x7fff99ae72d0, msg=0x7fbac961f958, res=0x7fff99ae6fe8, rve=0x7fbac95d1610) at rvalue.c:1895
#6  0x00000000004c9ace in rval_expr_eval_int (h=0x7fff99ae72d0, msg=0x7fbac961f958, res=0x7fff99ae6fe8, rve=0x7fbac95d2538) at rvalue.c:2117
...
(gdb) p avp
$12 = (sr_xavp_t *) 0x7fbaae0360d0
(gdb) p *avp
$13 = {id = 2085639187, name = {s = 0x7fbaae036108 "ulattrs", len = 7}, val = {type = SR_XTYPE_XAVP, v = {i = -1375510160, s = {s = 0x7fbaae036170 "\305\345om", len = 0}, t = 140439760101744, l = 140439760101744, ll = 140439760101744,
      xavp = 0x7fbaae036170, data = 0x7fbaae036170}}, next = 0x7fbaae036228}
(gdb) p *avp->next
$14 = {id = 2085639187, name = {s = 0x7fbaae036260 "ulattrs", len = 7}, val = {type = SR_XTYPE_NULL, v = {i = 0, s = {s = 0x0, len = 0}, t = 0, l = 0, ll = 0, xavp = 0x0, data = 0x0}}, next = 0x7fbaae0360d0}
(gdb) frame 0
#0  0x0000000000544235 in xavp_get_internal (name=0x7fbac95d11f8, list=0x7fbaae036248, idx=0, prv=0x0) at xavp.c:267
267                     if(avp->id==id && avp->name.len==name->len
(gdb) list
262                     avp = *list;
263             else
264                     avp = *_xavp_list_crt;
265             while(avp)
266             {
267                     if(avp->id==id && avp->name.len==name->len
268                                     && strncmp(avp->name.s, name->s, name->len)==0)
269                     {
270                             if(idx==n)
271                                     return avp;
(gdb)
272                             n++;
273                     }
274                     if(prv)
275                             *prv = avp;
276                     avp = avp->next;
277             }
278             return NULL;
279     }
280
281     sr_xavp_t *xavp_get(str *name, sr_xavp_t *start)

I assume these linked lists should be NULL terminated (i.e. avp->next == NULL) and therefore it is a bug that my list above is a loop.
My server has got stuck because it is searching for the name of an item that is inside the nested 'ulattrs' xavp.
Can someone explain the purpose of the SR_XTYPE_NULL entry?

Can anyone else see a problem either with my patch or the xavp add/insert code that it calls? I based my patch on the code in uldb_preload_attrs(), also in udomain.c.

Regards,
Hugh
________________________________
This e-mail and any attachment is for authorised use by the intended recipient(s) only. It may contain proprietary material, confidential information and/or be subject to legal privilege. It should not be copied, disclosed to, retained or used by, any other party. If you are not an intended recipient then please promptly delete this e-mail and any attachment and all copies and inform the sender. Thank you for understanding.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sip-router.org/pipermail/sr-dev/attachments/20141007/82b442b9/attachment-0001.html>