[reSIProcate] Stability for use in commercial release

[Craig Kaes <CKaes@xxxxxxxxxx>]

I've been evaluating various open source sip stacks for use in a commercial
product.  Of all the stacks, resiprocate has all the features that I want
(or close enough), and an extremely intuitive API that makes it easy to use.
Having a few sample apps makes it even easier.  The only other open source
stack under consideration at this point is GNU's osip, but my goodness what
a terrible interface!  50 different callbacks just to get started....

I do, however, have some concerns about the stability of resiprocate.  I've
seen postings of memory leaks and list a couple of my own problems below.  I
have three questions -- 
    1) Are folks using this stack for commercial offerings?
    2) For those who are, are you happy with it?
    3) I've done my testing on the plain ol' tarball release (0.4.0).
Should I be trying out head?  Is there a more recent label with fewer
issues?

--C

My issues:

I've been chasing a strange bug for a while and have boiled it down to a
very small test case that shows creating a SipStack corrupting memory
immediately prior to the stack's address. I only did a simple
./configure;make, so I've got static libs.  I'm running on Gentoo Linux.

craigk@caley cpp $ cat stg1.cpp

#include <resiprocate/SipStack.hxx>

int main(int argc, char* argv[])
{
    int i = 1;
    int j = 2;
    int k = 3;

    cerr << "i = " << i << ", j = " << j << ", k = " << k << endl;
    resip::SipStack stack1;
    cerr << "i = " << i << ", j = " << j << ", k = " << k << endl;
    return 0;
}

craigk@caley cpp $ g++ -o stg1 stg1.cpp -pthread -lpthread
-I/usr/local/resiprocate-0.4.0
-L/usr/local/resiprocate-0.4.0/resiprocate/obj.debug.Linux.i686
-L/usr/local/resiprocate-0.4.0/contrib/ares -lresiprocate -lares -lssl
craigk@caley cpp $ ./stg
stg   stg1
craigk@caley cpp $ ./stg1
i = 1, j = 2, k = 3
i = 1, j = 0, k = 135840264

In my actual code, this showed up as a corrupt stack and a segfault.  I put
in some padding in front of the stack to workaround this issue to see how
far I could then get.  The very first message that I receive triggers the
assertion in Logger.cxx.  What does this assertion point to in terms of how
I'm using the stack?  Am I doing something inappropriate?

--C