linphone-users
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Simon Morlat
Subject: Re: [Linphone-users] Bug: linphone-1.3.5 segfault on OpenBSD 3.9 with libOSSlib
Date: Tue, 6 Jun 2006 16:43:02 +0200
User-agent: KMail/1.9.1

Hello,

The oss support has been redesigned recently. Can you try with the 1.3.99.4 
tarball at 
http://download.savannah.nongnu.org/releases/linphone/unstable/source/
 ?
Thanks

Simon

Le Dimanche 4 Juin 2006 21:15, Michael Grigoni a écrit :
> 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
>
>
>
>
>
>
>
>
> _______________________________________________
> Linphone-users mailing list
> address@hidden
> http://lists.nongnu.org/mailman/listinfo/linphone-users




reply via email to

[Prev in Thread] Current Thread [Next in Thread]