< Previous by Date | Date Index | Next by Date > |
< Previous in Thread | Thread Index | Next in Thread > |
Hi Scott,sorry that it took me so long to get back to you, I was swamped with other things here.As you said, the crash must have been caused by something completely different as I cannot reproduce it anymore.I will revert the temporary changes I had made here in our local branch and keep an eye on it just in case it comes back. Will keep you posted if/when I have more details.
thanks for looking into it.regards,-Yannick2013/1/28 Scott Godin <slgodin@xxxxxxxxx>
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?ScottOn Fri, Jan 18, 2013 at 2:56 PM, Yannick Guay <yannick.guay@xxxxxxxxx> 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.cxxMethod name: ParseBuffer::fail(const char* file, unsigned int line, const Data& detail) constLine number: 957The 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
Attachment:
testSipMessage.cxx
Description: Binary data