RE: [reSIProcate] Request for help with crashes in header processing
> From: jason.fischl@xxxxxxxxx [mailto:jason.fischl@xxxxxxxxx]
> Sent: Tuesday, September 13, 2005 10:31 AM
>
> On 9/13/05, Dennis Dupont <ddupont@xxxxxxxxxxxxxxx> wrote:
> > I have been struggling for a week with crashes in
> resiprocate that I
> > am unable to debug. Any help someone more familiar with the code
> > could provide would be *most* appreciated as I am rapidly
> approaching
> > a major deployment. I am using the 0.9.0-5019 public
> tarball and I am
> > not using
> >
>
> One thing to check is that you are building with a consistent
> value of RESIP_LOCAL_DATA_SIZE defined when you build your
> application as when you compiled the library. This is used in
> Data.hxx
This has bit me before, but since moving to 0.9.0, I assume all that
is taken care of in config.hxx, so I have been passing HAVE_CONFIG_H
to my application compiles. I have also been only using the default
of 16 since I don't really trust that (see my earlier post on
HAVE_CONFIG_H vs HAVE_CONFIG_HXX)
>
> Have you tried valgrind?
I have not tried valgrind because this takes a very large load to
reproduce it. My experience with valgrind is that it can only be
useful if I am processing one or two messages at a time. According
to the StatisticsMessages, I am running at about 133 transactions
per second.
>
> Can you reproduce the problem with any of the test programs -
> such as testStack?
I will run that. I did not see it in the build output, but a
little digging shows I can build it manually (make check)
Can you simplify your application and get
> the same behavior out of it? Can you provide any hints as to
> what your application does?
>
It would be tough to do that and still run the test I am running,
but I will give that a try. My app is a B2BUA with an interface
to a an external call router. There is a ConnectionManager that
deals with cross connecting RTP streams, a service interface to
the external call router and a CallManager that interfaces to
resip. The CallManager has 2 threads, one to listen to the other
components (which calls SipStack::send) and another that calls
SipStack::receive. Shared between these two are state machine
objects that process the received sip messages and depending on
state and internal requests make the appropriate calls to send
sip messages.
My best guess on this problem is that the state machine objects
are messing up the messages somehow, either through stomping on
memory or deleting/reusing objects that the stack is using. I
just cannot see how given the way that the stack copies everything
I give it. My hope is that someone else can see the breadcrumbs
left behind.