[reSIProcate] Fwd: Re: crash on mailformed From field.

[roman.romanchenko at portaone.com]

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> 
> 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 [2]
>>>> https://list.resiprocate.org/mailman/listinfo/resiprocate-devel 
>>>> [1] [3]
>>>
>>> Links:
>>> ------
>>> [1] mailto:sip%3AXXXXX at sip.test.com
>>> [2] mailto:resiprocate-devel at resiprocate.org
>>> [3] https://list.resiprocate.org/mailman/listinfo/resiprocate-devel 
>>> [1]
>>> [4] mailto:roman.romanchenko at portaone.com
>>
>> _______________________________________________
>> resiprocate-devel mailing list
>> resiprocate-devel at resiprocate.org
>> https://list.resiprocate.org/mailman/listinfo/resiprocate-devel [1]
>
>
>
> Links:
> ------
> [1] https://list.resiprocate.org/mailman/listinfo/resiprocate-devel