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