[reSIProcate] crash on mailformed From field.

Fri Mar 22 11:05:45 CDT 2013

Ah - another case where we should be catching BaseException.  I've
committed another fix.  Thanks for helping to flush this out.

Scott

On Fri, Mar 22, 2013 at 2:12 AM, <roman.romanchenko at portaone.com> wrote:

> Dear Scott,
>
> Thanks for the fix, but... it does not work fine.
>
> Because:
>
> 1. Message with invalid From field received.
> 2. on calculating transaction Id, ParseException thrown.
> 3. Base exception catched and then : DebugLog( <<
> "TransactionState::process dropping message with invalid tid " <<
> message->brief());
> 4. The same exception thrown again. Because of message->brief() call.
>
> So you need remove message->brief() call from debug message
> (TransactionState.cxx:473).
>
> Thanks.
>
>
> On 2013-03-19 18:01, Scott Godin wrote:
>
>> 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<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>[1] [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>[1]
>>>> [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>[1]
>>>
>>
>>
>>
>> Links:
>> ------
>> [1] https://list.resiprocate.org/**mailman/listinfo/resiprocate-**devel<https://list.resiprocate.org/mailman/listinfo/resiprocate-devel>
>>
>
> ______________________________**_________________
> 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/20130322/a5c1a74d/attachment.htm>