Re: [reSIProcate] Problem in debian, not in Windows
It must be my application, ok guys, thank you, i let you know if i find something.
On 5/3/06, Daniel Pocock <
daniel@xxxxxxxxxxxxxxxxxxxxx> wrote:
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
>
_______________________________________________
resiprocate-devel mailing list
resiprocate-devel@xxxxxxxxxxxxxxxxxxx
https://list.sipfoundry.org/mailman/listinfo/resiprocate-devel