Re: [reSIProcate] crash on mailformed From field.
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@xxxxxxxxxxxx>
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@xxxxxxxxxxxxxxx [2]
https://list.resiprocate.org/mailman/listinfo/resiprocate-devel
[1] [3]
Links:
------
[1] mailto:sip%3AXXXXX@xxxxxxxxxxxx
[2] mailto:resiprocate-devel@xxxxxxxxxxxxxxx
[3] https://list.resiprocate.org/mailman/listinfo/resiprocate-devel
[1]
[4] mailto:roman.romanchenko@xxxxxxxxxxxx
_______________________________________________
resiprocate-devel mailing list
resiprocate-devel@xxxxxxxxxxxxxxx
https://list.resiprocate.org/mailman/listinfo/resiprocate-devel [1]
Links:
------
[1] https://list.resiprocate.org/mailman/listinfo/resiprocate-devel