RE: [reSIProcate] Problem in debian, not in Windows
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 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