[Linphone-developers] Problem with an infinite loop in bcg729 codec

[BOITEUX, FREDERIC]

        Hello,

We're using the Linphone G729 codec (bcg729) in our software (which handles 
multiple communications at the same time), it runs fine, except from time to 
time, where it runs into an endless loop, freezing all current communications 
(until software restart). I'm not always able to access the system when the 
lock-up has started, but I achieve to get 2 core dumps for this problem.
I've tried to analyze problem origin ; the endless loop occurs in VAD 
processing :

(gdb) bt
#0  countLeadingZeros (x=0) at utils.h:113
#1  g729Log2_Q0Q16 (x=-4096) at g729FixedPointMath.h:65
#2  bcg729_vad (VADChannelContext=0x7fe20c513040, 
    reflectionCoefficient=2065246114, 
    LSFCoefficients=LSFCoefficients@entry=0x7fe235e8f940, 
    
autoCorrelationCoefficients=autoCorrelationCoefficients@entry=0x7fe235e8fa70, 
    autoCorrelationCoefficientsScale=<optimized out>, 
    signalCurrentFrame=0x7fe20c940680) at vad.c:206
#3  0x00007fe234c276c3 in bcg729Encoder (encoderChannelContext=0x7fe20c940590, 
    inputFrame=<optimized out>, 
    bitStream=0x7fe20c9fa9d0 "\320j\356e\253\266\061O\214K\n", 
    bitStreamLength=0x7fe20c9fa9da "\n") at encoder.c:170
#4  0x00007fe235be90ff in md_g729Encoder_encode (sess=0x7fe231e8fc80, 
    encoderData=0x7fe20c9fa980, in=0x7fe2280b78c0)
    at ./threadPool_impl/src/modules/codecG729.c:391
#5  0x00007fe235bdaa8e in sessionSendReceiveProcess (worker=0x55cc9e74e200, 
    session=0x7fe231e8fc80, arg=<optimized out>)
    at ./threadPool_impl/src/sessionProcess.c:184
#6  0x00007fe235bd673b in workerRun (arg=0x55cc9e74e200)
    at ./threadPool_impl/src/scheduler.c:609
#7  0x00007fe2357364a4 in start_thread (arg=0x7fe235e90700)
    at pthread_create.c:456
#8  0x00007fe235174d0f in clone () at 
../sysdeps/unix/sysv/linux/x86_64/clone.S:97

The frames 0 to 3 are located in the bcg729 codec. In the frame #1, the source 
of g729Log2_Q0Q16() function states explicitely that its input must be > 0 and 
is not checked, and in the 2 cores, the given value was < 0.

I've tried to reproduce the problem, first with some of our automated calls 
systems (without success), then in a standalone program, trying to call the 
bcg729 codec with the PCM frame that causes the core dump, trying to set the 
VADContext to the same state that in the core, but I didn't success (I think 
perhaps some of these context variables were already modified between start of 
input frame processing and when the bug occurs). I'm a bit lost in the VAD 
processing anyway.

Did you experienced such kind of problem ?
Have you any clue about how to solve this endless loop ?

  Any help would be appreciated, thanks !

        Frédéric Boiteux - Odigo IVR product development
This message contains information that may be privileged or confidential and is 
the property of the Capgemini Group. It is intended only for the person to whom 
it is addressed. If you are not the intended recipient, you are not authorized 
to read, print, retain, copy, disseminate, distribute, or use this message or 
any part thereof. If you receive this message in error, please notify the 
sender immediately and delete all copies of this message.