[ previous ] [ next ] [ threads ]
 To :  yate@v...
 From :  Etoile =?iso-8859-15?q?Di=E8se?= <support@e...>
 Subject :  Re: [yate] Still Yate SIGSEGV regularly : problem found
 Date :  Thu, 3 Aug 2006 19:07:15 +0200
Hello,

Since Diana spoke about a tempo problem, we looked at this kind of thing and found that :
http://www.asteriskguru.com/tutorials/pci_irq_apic_tdm_ticks_te410p_te405p_noise.html

When an ISDN machine with a Digium card (at least) is heavy loaded, the sound is bad and the Zaptel driver causes problems that we suppose are the cause of our cores.
So we activated the APIC to allocate a private IRQ to the Digium card (instead of a shared one) and no more crash.

The symptoms are :
- Many D-channel down in the logs of Yate and sometime no D-channel up after it
- Some "kernel loosing ticks" or messages from the sata driver in syslog
- vmstat with cpu idle always very low and cpu system quite hight
- Undebuggable Segmentation cores from Yate
- zttest from the Zaptel test suite giving many values lower than 95%

This message maybe may help someone out there. I thank the Yate team and sorry for daring suspect that Yate is able to core by itself.

Regards.

Le Vendredi 28 Juillet 2006 16:17, Etoile Dièse a écrit :
> Hello,
> Yesterday, Diana tried to debug our problem using the core file. But the core did not correspond to the version currently installed : last CVS.
> Today we have three other cores of two different types. Here are the stacks :
> 
> first type :
> 
> #0  0x0000000000000000 in ?? ()
> #1  0x0000002a957b406e in TelEngine::ThreadedSource::stop (this=0x5a40f0) at DataFormat.cpp:874
> #2  0x0000002a963a51e2 in ~WaveSource (this=0x5a40f0) at wavefile.cpp:176
> #3  0x0000002a957a213a in TelEngine::RefObject::deref (this=0x5a40f0) at TelEngine.cpp:506
> #4  0x0000002a957b5b2c in TelEngine::DataEndpoint::setSource (this=0x589570, source=0x5a1480) at DataFormat.cpp:751
> #5  0x0000002a963a7866 in (anonymous namespace)::AttachHandler::received (this=0x5908b0, msg=@0x583bb0) at wavefile.cpp:556
> #6  0x0000002a957afa93 in TelEngine::MessageDispatcher::dispatch (this=0x501ad0, msg=@0x583bb0) at Message.cpp:318
> #7  0x0000002a957afe22 in TelEngine::MessageDispatcher::dequeueOne (this=0x501ad0) at Message.cpp:392
> #8  0x0000002a957afe5c in TelEngine::MessageDispatcher::dequeue (this=0x501ad0) at Message.cpp:399
> #9  0x0000002a957b07e9 in TelEngine::EnginePrivate::run (this=0x5908b0) at Engine.cpp:210
> #10 0x0000002a957aaccc in TelEngine::ThreadPrivate::run (this=0x57d330) at Thread.cpp:281
> #11 0x0000002a957aad02 in TelEngine::ThreadPrivate::startFunc (arg=0x57d330) at Thread.cpp:435
> #12 0x0000002a956719a4 in start_thread () from /lib64/tls/libpthread.so.0
> #13 0x0000002a95e13463 in clone () from /lib64/tls/libc.so.6
> 
> second type :
> 
> #0  0x0000002a95dbdaa5 in free () from /lib64/tls/libc.so.6
> #1  0x0000002a957a3674 in ~String (this=0x5966a8) at String.cpp:266
> #2  0x0000002a963a5d90 in ~WaveConsumer (this=0x596620) at wavefile.cpp:380
> #3  0x0000002a957a213a in TelEngine::RefObject::deref (this=0x596620) at TelEngine.cpp:506
> #4  0x0000002a957b59c7 in TelEngine::DataEndpoint::setConsumer (this=0x5afb70, consumer=0x582620) at DataFormat.cpp:792
> #5  0x0000002a963a77fb in (anonymous namespace)::AttachHandler::received (this=0x635ae05ee4da6469, msg=@0x5afff0) at wavefile.cpp:565
> #6  0x0000002a957afa93 in TelEngine::MessageDispatcher::dispatch (this=0x501ad0, msg=@0x5afff0) at Message.cpp:318
> #7  0x0000002a957afe22 in TelEngine::MessageDispatcher::dequeueOne (this=0x501ad0) at Message.cpp:392
> #8  0x0000002a957afe5c in TelEngine::MessageDispatcher::dequeue (this=0x501ad0) at Message.cpp:399
> #9  0x0000002a957b07e9 in TelEngine::EnginePrivate::run (this=0x635ae05ee4da6469) at Engine.cpp:210
> #10 0x0000002a957aaccc in TelEngine::ThreadPrivate::run (this=0x590e10) at Thread.cpp:281
> #11 0x0000002a957aad02 in TelEngine::ThreadPrivate::startFunc (arg=0x590e10) at Thread.cpp:435
> #12 0x0000002a956719a4 in start_thread () from /lib64/tls/libpthread.so.0
> #13 0x0000002a95e13463 in clone () from /lib64/tls/libc.so.6
> 
> In both cases, the problem occurs on a memory liberation. I am convinced that there is a memory bug in wavefile but I can't catch it.

-- 
Support Etoile Dièse