At 10/8/2008 11:02 AM, Alexander Chemeris wrote:
> > and finally
> >
> >
> "2008-09-19T13:23:24.482000Z":433:KERNEL:CRIT:vpc-vs4sipxtapi::00000000:sipXtapi:"OsMsgPool::FindFreeMsg
> > 'MediaSignals' queue size (64) exceeds hard limit (64)"
>
>This messages usually mean that some flowgraph is blocked
>and don't want to process messages, sent to it. To debug this,
>you should pause the process from debugger and see where
>is Mediatask thread looping. Few iterations should give you
>a clue about the place where infinite loop occurred.
>Posts this information here, and we'll be able to help you better.
The "exceeds soft/hard limit" messages are less common today, using
newly downloaded source code from the relocated SVN
repository. However, ReceiveCall still starts consuming 100% of CPU
shortly after I connect, like it did previously. When I break into
the debugger, MpMedia thread is looping in MprDecode::doProcessFrame
(MprDecode.cpp). It's the main loop:
// Pull packets from JB queue, till we won't get enough samples to playback
...
while (mpJB->getSamplesNum() < mpFlowGraph->getSamplesPerFrame())
{
...
}
mpJB->getSamplesNum() returns 0, and
mpFlowGraph->getSamplesPerFrame() returns 80. Over and over. I just
watched > 50 loops, always with the same values for those two.
ReceiveCall never ends by itself in this case (which is every case
today when it received an incoming call).
> > In addition, I sometimes get an access violation here:
> >
> > // Returns the flow graph that contains this resource or NULL if the
> > // resource is not presently part of any flow graph.
> > MpFlowGraphBase* MpResource::getFlowGraph(void) const
> > {
> > return mpFlowGraph; // <--access violation here
> > }
>
>Please, post full stack trace to this position.
>And any information when does this occurs.
When it happens again, I will. It hasn't happened today.
Finest regards,
Bill Root
_______________________________________________
sipxtapi-dev mailing list
[email protected]
List Archive: http://list.sipfoundry.org/archive/sipxtapi-dev/
