reSIProcate

Mailing Lists

Source Code

Google Search:



< Previous by Date Date Index Next by Date >
< Previous in Thread Thread Index Next in Thread >

Re: [reSIProcate] ParseBuffer::assertNotEof() ?



Byron Campen wrote:
That is not valid syntax, no. However, it would make sense to interpret this as the case where there is no tag parameter, and if this is something that a TU cannot live with, then it can be rejected there. Any objections? 


I'm still seeing this behaviour in the latest code from SVN.
Does anyone object if I patch this to allow the tag= nothing syntax, or is there another preferred solution? 


Best regards,
Byron Campen



Looking at my own case below, is the packet with an empty `tag='
parameter valid?

To: "Booth2" <sip:11@xxxxxxxxxxxxxxxxxxxxx>;tag=

Line 28 of DataParameter.cxx calls pb.assertNotEof(); - could the
following be done safely:

if(pb.eof()) {
  mValue = Data("");
  return;
}
or is there some other code that depends on the parameter having a value? 


Byron Campen wrote:


    This sounds like a bug in dum. If an exception due to a parse
failure is making it out of dum, then it is very likely the stack has
leaked a TransactionState. If the exception is not caught in the
appropriate place, not only is the SipMessage leaked, but there is no
way to respond to it, meaning the TransactionState will never get
cleaned up either (the stack waits indefinitely for the TU to respond). 

    Unfortunately, there are many such bugs, because a lot of the
code  was written before we transitioned to a lazy-parser, and the
code was  never fixed. The upshot is that calling something like
msg.header (h_HeaderName).someAccessor() will probably be what
triggers the  parse of the header, and if that header is malformed,
kaboom!

    Fixing all the instances of this will take some time. I tried my
best to clear up any errors of this type that existed in the stack
(and I think I've gotten them all). I think that, at this point, it
would make sense to add bool LazyParser::isWellFormed(), so we can
check whether the header is well-formed in an exception-safe manner.
This will make fixing the existing code a little easier. And for
those who are writing new code, keep this in mind!

    Now, I added a bandage for this problem that people can use in
the  meantime. As a configure option, you can set PEDANTIC_STACK to
true,  which cause the stack to do a full parse of SipMessages on
receipt.  If a problem is discovered, it will be rejected  immediately.
(ie, no  potential for a parse to fail later down the line, since
everything  is already parsed) This is an expensive solution, but at
least you  have the option.

Best regards,
Byron Campen




Occasionally, my application is receiving a packet which causes
assertNotEof() to throw an exception.

How is this exception meant to be dealt with?  Am I intended to
catch it
with a try { } catch { } block around dum->process()?  Or should  this
exception be caught and handled (presumably by discarding the  packet)
within the stack?

Here is the content of pb when the exception is thrown, the code in
DataParameter.cxx suggests the empty ;tag= is the fault:

(gdb) print pb
$1 = (class resip::ParseBuffer &) @0xbfffe114: {
  static Whitespace = 0xb7ac4264 " \t\r\n",
  static ParamTerm = 0xb7ac4261 ";?",
  mBuff = 0x809dd4a "\"Booth2\"
<sip:11@xxxxxxxxxxxxxxxxxxxxx>;tag=\r\nTo:
<sip:11@xxxxxxxxxxxxxxxxxxxxx>;tag=\r\nContact:
<sip:11@xxxxxxxxxx:5070>\r\nSupported: replaces\r\nProxy- Authorization: 
Digest username=\"11\", realm=\"sip."..., mPosition = 0x809dd76 "\r
\nTo:
<sip:11@xxxxxxxxxxxxxxxxxxxxx>;tag=\r\nContact:
<sip:11@xxxxxxxxxx:5070>\r\nSupported: replaces\r\nProxy- Authorization: Digest username=\"11\", realm=\"sip.callshop.lvdx.com\", algorithm=MD5, 
uri=\"sip:"...,
  mEnd = 0x809dd76 "\r\nTo:
<sip:11@xxxxxxxxxxxxxxxxxxxxx>;tag=\r\nContact:
<sip:11@xxxxxxxxxx:5070>\r\nSupported: replaces\r\nProxy- Authorization: Digest username=\"11\", realm=\"sip.callshop.lvdx.com\", algorithm=MD5, 
uri=\"sip:"...,
  mErrorContext = @0xb7dc5c18}


Regards,

Daniel
_______________________________________________
resiprocate-devel mailing list
resiprocate-devel@xxxxxxxxxxxxxxxxxxx
https://list.sipfoundry.org/mailman/listinfo/resiprocate-devel





_______________________________________________
resiprocate-devel mailing list
resiprocate-devel@xxxxxxxxxxxxxxxxxxx
https://list.sipfoundry.org/mailman/listinfo/resiprocate-devel