[reSIProcate] Problem in debian, not in Windows

[lucas martinez]

It must be my application, ok guys, thank you, i let you know if i find
something.

On 5/3/06, Daniel Pocock <daniel at readytechnology.co.uk> 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 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
> >
> _______________________________________________
> resiprocate-devel mailing list
> resiprocate-devel at list.sipfoundry.org
> https://list.sipfoundry.org/mailman/listinfo/resiprocate-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://list.resiprocate.org/pipermail/resiprocate-devel/attachments/20060503/174b0e45/attachment.htm>