[reSIProcate] HeaderNames issue
Scott Godin
slgodin at gmail.com
Mon Jan 28 12:55:37 CST 2013
Hi Yannick,
I ran the test code you posted against the trunk revision and did not
reproduce a crash. The Parse Exception threw as expected, but it did not
crash. When I look at the code the HeaderName array, is an array of Data
objects - these objects self initialize to an empty string. From what I
can tell, when you create a URI object that is not associated with any
header the HeaderType is set to Headers::UNKNOWN (-1) - see Uri.cxx
constructor line 60. When Headers::getHeaderName is called it adds 1 to
the header type and references it in the Headers array. This should just
access a Data object that represents an empty string. I'm not seeing the
issue. Perhaps something else is causing memory corruption in your copy of
the code?
Scott
On Fri, Jan 18, 2013 at 2:56 PM, Yannick Guay <yannick.guay at gmail.com>wrote:
> Hi Scott,
>
> Please find, attached a snippet of code that triggers the crash. Below is
> the exact location where it crashes:
> *File name:* rutil/ParseBuffer.cxx
> *Method name:* ParseBuffer::fail(const char* file, unsigned int line,
> const Data& detail) const
> *Line number: *957
>
> The version of resiprocate we're using here at Cassisian is 1.8.5. As
> well, please note the "tgrp=" user parameter which is empty in the snippet,
> this is what triggers the segfault, feeding ParseBuffer with a non-empty
> user parameter makes the bug go away.
>
> best regards,
> -Yannick
>
> 2013/1/17 <slgodin at gmail.com>
>
> sample code that illustrates this trap?
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://list.resiprocate.org/pipermail/resiprocate-devel/attachments/20130128/78ded1d9/attachment.htm>
More information about the resiprocate-devel
mailing list