[reSIProcate] crash on mailformed From field.
Scott Godin
sgodin at sipspectrum.com
Tue Mar 19 11:01:01 CDT 2013
I think the catch in TransactionState::process should be changed to catch
the wider BaseException. I have changed a couple of catches in
TransationState for this. Rev: 10051.
Thanks,
Scott
On Sun, Mar 17, 2013 at 3:54 PM, <roman.romanchenko at portaone.com> wrote:
> Dear developers,
>
> I'm not sure where the ParseException thrown during the call of
> getTransactionId() is catched.
>
> 1. Inside ParseBuffer, ParseException catched, then fail() called, and
> ParseException thrown again.
> 2. SipMessage class does not catch ParseException or it's base.
> 3. TransactionState::process calls getTransactionId() and catches
> SipMessage::Exception but not ParseException.
> 4. moving up through the call stack it is also not catch by
> TransactionController or TransactionControllerThread. So can be catch by my
> application level only, that is actually is not so good, to break the
> thread on such malformed fields like I have provided in first post.
>
> I have implemented simple workaround to catch ParseException right after
> catch (SipMessage::Exception) block in TransactionState::process().
> On the moment of catch it is even not ready to answer with "Bad Request"
> or something like this. So I just delete message, write error message to
> log and return from process().
>
> But I'm interesting in some kind of "official" solution here, or just
> estimation when it can be released.
>
> Thanks.
>
>
> On Thu, 14 Mar 2013 08:23:04 -0700, Byron Campen wrote:
>
>> A couple of potential causes; terminate can be called when an
>> exception specification is violated, or if another exception is thrown
>> while the first is propogating (usually caused by a throw inside a
>> destructor, which is why throwing inside a destructor is generally a
>> bad idea).
>>
>> Best regards,
>> Byron Campen
>> On Mar 14, 2013 7:04 AM, wrote:
>>
>> Dear resiprocate devels.
>>>
>>> I have the following issue.
>>>
>>> resiprocate 1.8.5
>>>
>>> On receiving the first REGISTER message with mailformed From field
>>> included extra space before ">", my application based on resiprocate
>>> crashes into core.
>>> Here is an example: From:
>>>
>>> I expect that TransactionState::process would handle this in place
>>> where calling getTransactionId() and print something to log or call
>>> handleBadRequest()
>>>
>>> Please advice.
>>>
>>> Many thanks.
>>>
>>> gdb stack for more details:
>>>
>>> #0 0x0000003c524328a5 in raise () from /lib64/libc.so.6
>>> #1 0x0000003c52434085 in abort () from /lib64/libc.so.6
>>> #2 0x0000003c554bea5d in __gnu_cxx::__verbose_**terminate_handler()
>>> () from /usr/lib64/libstdc++.so.6
>>> #3 0x0000003c554bcbe6 in ?? () from /usr/lib64/libstdc++.so.6
>>> #4 0x0000003c554bcc13 in std::terminate() () from
>>> /usr/lib64/libstdc++.so.6
>>> #5 0x0000003c554bcd0e in __cxa_throw () from
>>> /usr/lib64/libstdc++.so.6
>>> #6 0x0000003c5d63fb8a in resip::ParseBuffer::fail
>>> (this=0x7f5cf3ffe180, file=0x3c5d66493f "ParseBuffer.cxx", line=62,
>>> detail=) at ParseBuffer.cxx:964
>>> #7 0x0000003c5d6406bc in resip::ParseBuffer::skipChar
>>> (this=0x7f5cf3ffe180, c=62 >) at ParseBuffer.cxx:62
>>> #8 0x0000003c5eedbaf9 in resip::NameAddr::parse
>>> (this=0x7f5c5d96ba60, pb=...) at NameAddr.cxx:241
>>> #9 0x0000003c5ef27d9c in resip::LazyParser::doParse (this=) at
>>> LazyParser.cxx:79
>>> #10 0x0000003c5eed6af0 in checkParsed (this=0x7f5c5d96ba60,
>>> paramType=...) at ../../resip/stack/LazyParser.**hxx:106
>>> #11 resip::NameAddr::exists (this=0x7f5c5d96ba60, paramType=...) at
>>> NameAddr.cxx:434
>>> #12 0x0000003c5ef61266 in
>>> resip::SipMessage::**compute2543TransactionHash (this=0x7f5c5d96b4c0)
>>> at SipMessage.cxx:424
>>> #13 0x0000003c5ef61e28 in resip::SipMessage::**getTransactionId
>>> (this=0x7f5c5d96b4c0) at SipMessage.cxx:357
>>> #14 0x0000003c5ef8641a in resip::TransactionState::**process
>>> (controller=..., message=0x7f5c5d96b4c0) at TransactionState.cxx:468
>>> #15 0x0000003c5ef77720 in resip::TransactionController::**process
>>> (this=0x563ffa0, timeout=) at TransactionController.cxx:141
>>> #16 0x0000003c5ef69f81 in
>>> resip::**TransactionControllerThread::**thread (this=0x3e81460) at
>>> ../../resip/stack/**TransactionControllerThread.**hxx:30
>>> #17 0x0000003c5d646e3a in threadIfThreadWrapper (threadParm=) at
>>> ThreadIf.cxx:51
>>> #18 0x0000003c52c07851 in start_thread () from
>>> /lib64/libpthread.so.0
>>> #19 0x0000003c524e811d in clone () from /lib64/libc.so.6
>>>
>>> ______________________________**_________________
>>> resiprocate-devel mailing list
>>> resiprocate-devel at resiprocate.**org <resiprocate-devel at resiprocate.org>[2]
>>> https://list.resiprocate.org/**mailman/listinfo/resiprocate-**devel<https://list.resiprocate.org/mailman/listinfo/resiprocate-devel>[3]
>>>
>>
>>
>> Links:
>> ------
>> [1] mailto:sip%3AXXXXX at sip.test.**com <sip%253AXXXXX at sip.test.com>
>> [2] mailto:resiprocate-devel@**resiprocate.org<resiprocate-devel at resiprocate.org>
>> [3] https://list.resiprocate.org/**mailman/listinfo/resiprocate-**devel<https://list.resiprocate.org/mailman/listinfo/resiprocate-devel>
>> [4] mailto:roman.romanchenko@**portaone.com<roman.romanchenko at portaone.com>
>>
>
> ______________________________**_________________
> resiprocate-devel mailing list
> resiprocate-devel at resiprocate.**org <resiprocate-devel at resiprocate.org>
> https://list.resiprocate.org/**mailman/listinfo/resiprocate-**devel<https://list.resiprocate.org/mailman/listinfo/resiprocate-devel>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://list.resiprocate.org/pipermail/resiprocate-devel/attachments/20130319/0477dcc3/attachment.htm>
More information about the resiprocate-devel
mailing list