[Linphone-users] Bug: linphone-1.3.5 segfault on OpenBSD 3.9 with libOSSlib

[Michael Grigoni]

Greetings:

This report describes behavior of 'linphone' 1.3.5 compiled on
OpenBSD 3.9, gcc version 3.3.5 (propolice) (Thread model: single),
with libOSSlib from 4Front Technologies (www.opensound.com).
Previously I had reported the behavior of the program on the
same platform with the 'libossaudio' support that comes with
OpenBSD 3.9 (I had good one-way audio, from the remote UA to
linphone using a USB headset but only choppy audio and only
when DTMF tones broke the silence using the Intel ICH AC97
audio controller).

The libOSSlib support provides shadow duplex /dev/dsp devices; one
opens /dev/dsp1 for reading and /dev/dsp for writing for example.
I configured 'linphone' to use /dev/dsp1 for ringing and
playback and /dev/dsp for recording. The codec used is gsm.
Upon establishing the call (answering locally or on the remote
UA), linphone segfaults.  Here is a gdb 'bt full':

#0  0x05d1c5d2 in memcpy () from /usr/lib/libc.so.39.0
No symbol table info available.
#1  0x041dca9a in oss_card_write (obj=0x8a7ddc00, buf=0x7c4dc414 "", 
size=128)
    at osscard.c:305
        canwrite = 4096
        bsize = 2147366720
#2  0x041dbf4e in snd_card_write (obj=0x200, buffer=0x7c4dc414 "", size=512)
    at sndcard.c:71
No locals.
#3  0x041dfaae in ms_oss_write_process (f=0x82408f00) at msosswrite.c:131
        p = (void *) 0x7c4dc414
        i = -1971463168
        gran = 512
#4  0x041ce7fd in ms_thread_run (sync_ptr=0x82408f80) at ms.c:197
        filter = (GList *) 0x7d2d95c4
        f = (MSFilter *) 0x82408f00
#5  0x0a272828 in g_static_private_free ()
   from /usr/local/lib/libglib-2.0.so.800.4
No symbol table info available.
#6  0x04c32f3b in _thread_start ()
    at /usr/src/lib/libpthread/uthread/uthread_create.c:244
        curthread = (struct pthread *) 0x600
#7  0x0000001f in ?? ()
#8  0x00000000 in ?? ()

Additional notes ('listen' refers to the button in the sound
setup window):

1. When playback,  recording, and ringing devices are configured
   all to use /dev/dsp, and the first device opened is the
   recording device, there is only choppy, garbage audio
   and usually only from linphone to the remote UA.

2. When playback, recording and ringing are all on /dev/dsp as
   above but the first device opened is playback (forced by
   either 'listening' to the ring tone, or calling 'linphone'
   from the remote UA, there is clean one-way audio from
   the remote UA to 'linphone'.

3. When playback and ringing are on /dev/dsp and recording is
   on /dev/dsp1, trying to 'listen' to the ring tone
   reports that /dev/dsp1 cannot be opened; /dev/dsp1 is
   _not_ the device assigned to ringing.

4. When playback and ringing are on /dev/dsp1 and
   recording on /dev/dsp, ringing works properly, but establishing
   a call produces the segfault (this is the confuration for the
   backtrace).


Additional problem with 'linphonec':

  -- terminal input is detached; the program issues its prompt
     but accepts no input. After it is killed, any input typed
     from the terminal is echoed and evaulated (as shell input).

  -- the terminal shell is not 'bash' but either 'ksh' or /bin/sh.
     readline() works properly as I verified with a simple C
     program and there are default $HOME/.inputrc bindings in
     users' home directories.

  -- if 'linphonec' is invoked to automatically answer, and it
     uses the same settings saved from 'linphone' which segfault,
     it also segfaults (to be expected from the coreapi).

The use of 4Front libOSSlib should provide all of the expected
OSS services with standard behaviors and should remove any
uncertainties of the oss emulation provided in the OpenBSD 3.9
distribution.  Note that I compiled the test applications
'ossrecord' and 'ossplay' shipped with libOSSlib and they
work properly and simultaneously (one may record and play
at the same time using /dev/dsp for one and /dev/dsp1 for
the other).

I don't have lots of time to debug linphone and would appreciate
as much help as folks (and Simon) can provide.

Regards,

Michael Grigoni
Cybertheque Museum