[reSIProcate] HeaderNames issue
Yannick Guay
yannick.guay at gmail.com
Thu Jan 17 14:40:07 CST 2013
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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://list.resiprocate.org/pipermail/resiprocate-devel/attachments/20130117/14c7e5e0/attachment.htm>
More information about the resiprocate-devel
mailing list