Well even rc4 (1.2.0-rc4) is segfaulting and dropping calls :(
2007-07-19 10:48:38 - CW died!
2007-07-19 10:48:56 - CW died!
2007-07-19 10:49:18 - CW died!
Its 11:07 now, so at least its been up 18 minutes so far.
Here is the stack dump from rc4:
(gdb) bt full
#0 0xb7f1db66 in wait_for_hangup (chan=0xb6302de0, data=0x67003031)
at pbx.c:6285
res = <value optimized out>
f = <value optimized out>
waittime = <value optimized out>
#1 0xb7f1dc3a in pbx_builtin_congestion (chan=0xb6302de0, argc=1,
argv=0xb7f6c52c) at pbx.c:6332
No locals.
#2 0xb7f278fc in __opbx_pbx_run (c=0xb6302de0) at pbx.c:2900
status = 0x80d10c7 "CONGESTION"
digit = <value optimized out>
exten = '\0' <repeats 255 times>
pos = <value optimized out>
waittime = <value optimized out>
res = 0
hash = 201967687
__PRETTY_FUNCTION__ = "__opbx_pbx_run"
#3 0xb7f28938 in pbx_thread (data=0xb6302de0) at pbx.c:2987
No locals.
#4 0xb7e9e31b in start_thread () from /lib/tls/i686/cmov/libpthread.so.0
No symbol table info available.
#5 0xb7d7457e in clone () from /lib/tls/i686/cmov/libc.so.6
No symbol table info available.
------
RoyK suggested that it could be kernel-related somehow, so I build a debian
box and try
running
Im really running out of ideas here. If cant get this work by the end of
the week, my boss is forcing me to go back to old POTS system :(
As evil as this sounds, maybe I should try Asterisk and see if it says up?
Has anyone had any experience with Grandstream's FXS/FXO devices? Maybe
they are to blame.
----Original Message Follows----
From: Mike Jagdis <[EMAIL PROTECTED]>
Reply-To: Developers Mailing List <[email protected]>
To: Developers Mailing List <[email protected]>
CC: [EMAIL PROTECTED]
Subject: Re: [Callweaver-dev] CW segfaults every few hours! Help!
Date: Thu, 19 Jul 2007 12:14:22 +0100
On Thu, Jul 19, 2007 at 03:55:36AM +0000, MM _ wrote:
> Ive been having a massive problem with CW segfaulting for no apparent
> reason.
I've just committed one change to trunk and /branches/rel/1.2 to avoid
death and destruction. The issue was that a hangup other than at the end
of dialplan processing would leave the next steps trying to write a CDR
to the hung up channel. That races with the CDR posting to the CDR back
ends, which _sometimes_ leads to accessing freed data, which _sometimes_
gets reused quickly and which _sometimes_ results in following a bogus
next pointer into the nether reaches of hell. Where "sometimes" is
actually "bloody often" :-).
This may or may not be your problem. But if you're getting calls being
hung up due to packet loss / network badness then that's happening
while the Dial app is active so it may well be where the seg faults are
coming from.
Mike
P.S. Yeah, this is more a workaround than a true fix since it
undoubtedly is still racey (but a _lot_ less so). The locking/thread
"design" in the core really is "interesting".
--
Mike Jagdis Web: http://www.eris-associates.co.uk
Eris Associates Limited Tel: +44 7780 608 368
Reading, England Fax: +44 118 926 6974
_______________________________________________
Callweaver-dev mailing list
[email protected]
http://lists.callweaver.org/mailman/listinfo/callweaver-dev
_________________________________________________________________
Express yourself instantly with MSN Messenger! Download today it's FREE!
http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/
_______________________________________________
Callweaver-dev mailing list
[email protected]
http://lists.callweaver.org/mailman/listinfo/callweaver-dev
