[reSIProcate] Problem in debian, not in Windows

[Daniel Pocock]

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 at list.sipfoundry.org [mailto:resiprocate-devel-bounces at list.sipfoundry.org]On Behalf Of lucas martinez
>Sent: Tuesday, May 02, 2006 8:32 PM
>To: resiprocate-devel at list.sipfoundry.org
>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 at jasomi.com> 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 at list.sipfoundry.org
>https://list.sipfoundry.org/mailman/listinfo/resiprocate-devel
>