Re: [reSIProcate] Problem in debian, not in Windows

[Daniel Pocock <daniel@xxxxxxxxxxxxxxxxxxxxx>]

Bayart, Frederik wrote:

> Hi Lucas,
>
> I'm using the version 0.9.0 on debian (sarge en unstable), although I don't use 
> invites and I don't have any problem
>
> Frederik
>
>  
I'm also using reSIProcate on Debian, with two different products.  Both 
of them are handling several thousand calls/day.

> -----Original Message-----
> From: resiprocate-devel-bounces@xxxxxxxxxxxxxxxxxxx 
> [mailto:resiprocate-devel-bounces@xxxxxxxxxxxxxxxxxxx]On Behalf Of lucas 
> martinez
> Sent: Tuesday, May 02, 2006 8:32 PM
> To: resiprocate-devel@xxxxxxxxxxxxxxxxxxx
> Subject: Re: [reSIProcate] Problem in debian, not in Windows
>
>
> I will try this libraries, but i think that something is wrong under Debian, 
> someone is using Debian to run resiprocate???
>
>
> On 4/29/06, Alan Hawrylyshen < alan@xxxxxxxxxx> wrote: 
>
>
> On 28-Apr-06, at 5:09 PM, lucas martinez wrote: 
>
>  
>
> > I have the same application running in windows and in a linux box
> > (Debian), in windows everything runs perfect, but in debian im
> > getting an error when the phone is answered, here is the backtrace. 
> >
> > #0  0x407efd89 in free () from /lib/tls/libc.so.6
> > #1  0x40728d23 in operator delete () from /usr/lib/libstdc++.so.5
> > #2  0x40728d7f in operator delete[] () from /usr/lib/libstdc++.so.5
> > #3  0x4034cb1a in ~HeaderFieldValue (this=0x406d1caa) at 
> > HeaderFieldValue.cxx:51
> > #4  0x4036795b in resip::LazyParser::clear (this=0x4074bebc) at
> > LazyParser.cxx:88
> > #5  0x403677f7 in resip::LazyParser::operator= (this=0x4074bebc,
> > rhs=@0x808e8b0) at LazyParser.cxx:54
> > #6  0x403295b2 in resip::Contents::operator= (this=0x4074bebc,
> > rhs=@0x808e8b0) at Contents.cxx:103
> > #7  0x4039b372 in resip::SdpContents::operator= (this=0x4074bebc,
> > rhs=@0x808e8b0) at SdpContents.cxx:178
> > #8  0x08050bc9 in Call::setIncomingSdp (this=0x4074be64,
> > sdp=@0x808e8b0) at CallManager.cxx:82
> > #9  0x080516bd in CallManager::onOffer (this=0x8072e30, is={mHam =
> > 0x806f6d8, mId = 6}, msg=@0x808db20, sdp=@0x808e8b0) 
> >    at CallManager.cxx:188
> > #10 0x401540f5 in resip::InviteSession::dispatchSentReinviteNoOffer
> > (this=0x8087fc8, msg=@0x808db20)
> >    at InviteSession.cxx:1194
> > #11 0x40151eb4 in resip::InviteSession::dispatch (this=0x8087fc8, 
> > msg=@0x808db20) at InviteSession.cxx:720
> > #12 0x400f8a4f in resip::ClientInviteSession::dispatch
> > (this=0x8087fc8, msg=@0x808db20) at ClientInviteSession.cxx:392
> > #13 0x40114636 in resip::Dialog::dispatch (this=0x807a700, 
> > msg=@0x808db20) at Dialog.cxx:571
> > #14 0x40120bb0 in resip::DialogSet::dispatch (this=0x80854f8,
> > msg=@0x808db20) at DialogSet.cxx:760
> > #15 0x401323e9 in resip::DialogUsageManager::processResponse 
> > (this=0x806f6d8, response=@0x808db20)
> >    at DialogUsageManager.cxx:1590
> > #16 0x4012f002 in resip::DialogUsageManager::incomingProcess
> > (this=0x806f6d8, msg={_M_ptr = 0x808db20})
> >    at DialogUsageManager.cxx:1217
> > #17 0x4012e3f1 in resip::DialogUsageManager::internalProcess
> > (this=0x806f6d8, msg={_M_ptr = 0x0})
> >    at DialogUsageManager.cxx:1104
> > #18 0x4014430a in resip::DumThread::thread (this=0x8072e88) at 
> > DumThread.cxx:24
> > #19 0x4051fc42 in threadWrapper (threadParm=0x8072e88) at
> > ThreadIf.cxx:49
> > #20 0x4068db63 in start_thread () from /lib/tls/libpthread.so.0
> > #21 0x4085618a in clone () from /lib/tls/libc.so.6 
> >
> >
> >
> > last log message is:
> >
> >
> > INFO | 20060428-181508.768 | Apollo |  | RESIP:DUM | 13294 |
> > 1099656112 | InviteSession.cxx:2032 | Transition
> > InviteSession::SentReinviteNoOffer -> 
> > InviteSession::SentReinviteAnswered
> >
> >
> > Some one could give me a hand?? :)
> > _
> >    
>
> Crashes in free() / delete are frequently from double deletes.
> Consider linking against malloc_debug and looking for a double free 
> (I believe the library can be configured to report these). Another
> option under linux that is quite useful is to try using electric
> fence, from Bruce Perens.  It will force a trap if your program
> writes beyond the end of any memory allocated from the heap. You run 
> a second time to catch under-runs. It is an ingenious use of the MMU
> and memory alignment to force the malloc return values to be page
> aligned so overruns are caught in hardware.
>
> Hope that helps.
> Alan
>
>
>
>
>
>  
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> resiprocate-devel mailing list
> resiprocate-devel@xxxxxxxxxxxxxxxxxxx
> https://list.sipfoundry.org/mailman/listinfo/resiprocate-devel