[reSIProcate] some bug with static Router

[Scott Godin]

Hi Dragos,

I ran across a similar issue with push_front on Record-Route headers.
 After discussing with Byron Campen, he developed a fix that I just
submitted to SVN as rev:
11169<http://svn.resiprocate.org/viewsvn/resiprocate?view=rev&rev=11169>

I believe this will address your issue here as well.

Best Regards,
Scott Godin


On Mon, Jan 6, 2014 at 3:39 AM, Dragos Dinu <ddinu at ezuce.com> wrote:

> Hi Scott,
>
> I will try to post a small test to reproduce this. Btw, I meant "strict
> router".
>
> Thanks,
> Dragos
>
>
> On Fri, Jan 3, 2014 at 8:51 PM, Scott Godin <sgodin at sipspectrum.com>wrote:
>
>> Hi Dragos,
>>
>> I find it very odd that we wouldn't have seen an issue here before.  We
>> have done lots of testing with multiple Route and Record-Route headers.
>>  Can you post a small test program that exhibits the behaviour you are
>> talking about?
>>
>> Thanks,
>> Scott
>>
>>
>> On Fri, Jan 3, 2014 at 1:37 PM, Dragos Dinu <ddinu at ezuce.com> wrote:
>>
>>> Hi guys,
>>>
>>> I'm Dragos and I've recently been working with the resiprocate stack and
>>> DUM code. I encountered the following problem:
>>>
>>> *When sending a request to resiprocate DUM with a strict Record-Route
>>> URI, the Helper::processStrictRoute is called:*
>>>
>>> *      // The next hop is a strict router.  Move the next hop into the*
>>> *      // Request-URI and move the ultimate destination to the end of
>>> the*
>>> *      // route list.  Force the message target to be the next hop
>>> router.*
>>> *
>>>   request.header(h_Routes).push_back(NameAddr(request.const_header(h_RequestLine).uri()));*
>>> *      request.header(h_RequestLine).uri() =
>>> request.const_header(h_Routes).front().uri();*
>>> *      request.header(h_Routes).pop_front(); // !jf!*
>>>
>>>
>>> Before running this code, we already have a Route which should be
>>> replaced with the RequestLine.
>>>
>>> When pushing back the RequestLine in the routes vector, it seems that
>>> the associated HeaderFieldValue of the already existing Route header is
>>> deleted , probably because of a reallocation of the vector.
>>> This leads to the fact that when we try to set the uri of the
>>> RequestLine to the one of the Route, we try to use a freed buffer.
>>>
>>> So what I did was save the uri and use it afterwards:
>>>
>>> *      Uri frontRouteUri = request.const_header(h_Routes).front().uri();*
>>> *
>>> request.header(h_Routes).push_back(NameAddr(request.const_header(h_RequestLine).uri()));*
>>> *      //request.header(h_RequestLine).uri() =
>>> request.const_header(h_Routes).front().uri();*
>>> *      request.header(h_RequestLine).uri() = frontRouteUri;*
>>>
>>>
>>> Seems to work, but I was thinking to ask you for your more experienced
>>> opinion if this is the way to go. Thanks.
>>>
>>>
>>> Regards,
>>> Dragos
>>>
>>> _______________________________________________
>>> resiprocate-devel mailing list
>>> resiprocate-devel at resiprocate.org
>>> https://list.resiprocate.org/mailman/listinfo/resiprocate-devel
>>>
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://list.resiprocate.org/pipermail/resiprocate-devel/attachments/20140501/af8e4d2f/attachment.htm>