[reSIProcate] HeaderNames issue
slgodin at gmail.com
slgodin at gmail.com
Thu Jan 17 17:54:45 CST 2013
Hi Yannik,
What version/revision are you using? Do you have sample code that illustrates this trap?
Thanks,
Scott
Sent from my iPhone
On 2013-01-17, at 3:40 PM, Yannick Guay <yannick.guay at gmail.com> wrote:
> Hi,
>
> I've recently played around with the resiprocate's sip headers code and came across an issue with Headers::getHeaderName(int type).
>
> My code basically parses sip headers looking for user parameters and whenever they come in as empty, ParseBuffer::fail() is getting called but is unable to throw the proper exception and is segfaulting instead.
>
> I was able to trace it down to using an uninitialized item inside the HeaderNames array when trying to access an item with an index of "header type = NONE". The uninitialized Data object then gets used in the ParseBuffer::fail to construct the exception text description.
>
> I've temporarily patched the code in 2 places (in our repository):
> Ensured the given index (Headers::getHeaderName(int type)) is lesser then MAX_HEADERS. Otherwise returns a properly initialized but empty Data object.
> Appended mErrorContext to the exception description only if it's size is greater than zero.
> While this solution works as expected, it is meant as a stop gap measure as seems rather inefficient given that this method is consistently called over and over again. So I'm looking for a way to avoid the need to go through a condition every time Headers::getHeaderName() is called.
>
> Ideally all indexes in the array should be initialized such that I don't end up getting a reference to uninitialized memory but I'm not clear how this should be done. I've explored both resip/stack/Headers.cxx and resip/stack/Headers.hxx and would need guidance as to how Headers::HeaderNames[NONE] should be initialized to something valid.
>
> Can you guys please give me a hand with this issue?
>
> best regards,
> -Yannick Guay
> _______________________________________________
> 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/20130117/191b65d0/attachment.htm>
More information about the resiprocate-devel
mailing list