Re: [reSIProcate] "opt" builds
Hi,
Thanks for all the responses. I agree with the views
presented here. We had a resip assert earlier that helped
us figure out a problem with our usage and it was
definitely helpful.
My follow-up question to my earlier post is this. I
have run into a few instances where resiprocate has
asserted here:
ClientInviteSession.cxx:224:
Void ClientInviteSession::end(EndReason reason)
.....
.....
case Terminated:
assert(0); <=====
break;
To me, this looks like a case where end has been invoked
twice ( I have verified my usage of end() and I don't
think am calling it twice; this happens when we are
handling a high volume of calls and when the server
initiated the disconnect - unfortunately I don't have any
more traces/logs that will help me understand why this
gets triggered so ). In anycase, without understanding
much of the state transitions, I can't judge if the
assert() is called for. Can't resip handle this case
better? It just makes me suspicious if asserts are being
used to bail out of conditions that can probably still be
handled better....
Any help is understanding why resip is asserting on line
224 will be really great!
Thanks,
~Sunitha
> -----Original Message-----
> From: Adam Roach [mailto:adam@xxxxxxxxxxx]
> Sent: Wednesday, September 19, 2007 7:16 AM
> To: David Thompson
> Cc: 'Byron Campen';
resiprocate-devel@xxxxxxxxxxxxxxxxxxxx;
> Sunitha Beeram
> Subject: Re: [reSIProcate] "opt" builds
>
> David Thompson wrote:
> > Thank you for your thoughts and I agree with you. In
production we
> > *shouldn't* ever get to the asserts in the first
place. In
> my case, my
> > program will run into it once every couple of days,
and with a high
> > volume of other concurrent calls, I was attempting to
not have the
> > entire program recycle due to the one anomaly (for
> accounting reasons).
>
> Even without the assert()s, though, it's likely to dump
core
> anyway. If the condition enforced by an assert() is
false,
> you're probably going to end up dereferencing a null or
> stepping through a bad pointer in fairly short order.
>
> > BTW, am I correct in assuming the OPT build is the
best for final
> > production build?
> >
>
> I'm not certain that any thorough characterization of
the
> resip stack with regards to compilation options has
been
> undertaken recently enough to be relevant. If you're
> concerned with getting the most performance out of
resip, you
> might want to spend some time tinkering around with
various
> compile and link flags and profiling the resultant
code. You
> also might consider purchasing Intel's Linux compiler,
which
> is largely gcc compatible and produces somewhat faster
code than gcc.
>
> <shameless-plug>
> Alternately, if performance is a primary concern, you
might
> check with Estacado Systems, which has a
> performance-and-footprint optimized,
commercially-supported
> version of the resip stack that runs about 30% faster
than
> the publicly-available resip code. See
> <http://www.estacado.net/SIPBasis.html#foundation> for
information.
>
> (For full disclosure, I _am_ affiliated with Estacado
Systems).
> </shameless-plug>
>
> /a
>