[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