Hi,
You're not giving any useful information whatsoever. Still, what I can
say is that there is *one* condition to use Speex in a threaded
application: don't use a speex object (encoder/decoder state, a
SpeexBits struct, ...) in both threads at the same time. As long as you
satisfy that, you're OK. Speex itself has no state, so the library is
thread-safe (as long as you use it properly). If you still have crashes,
look at your own code for the bug.
Jean-Marc
Le mer 30/06/2004 ? 12:06, Julien Janier a ?crit :> Hy,
>
> I'm writing a application using speex.
> This app have two threads one is encoding the other one decoding using
> speex.
>
> I dont know why but I got segfault on some systems.
>
> If I juste take off one of the thread like encoding and lauchin the
> decoding part in a thread and the application is still segfaulting.
> But if I just launch the decoding process with out a thread every thing
> is going fine.
>
> So I would like to know if there are some special things I have to worry
> about when I'm using speex and threads.
>
> Thanks In advance.
>
>
> Here a backtrace of gdb :
>
> Program received signal SIGSEGV, Segmentation fault.
> [Switching to Thread 32771 (LWP 4367)]
> 0x40035bdb in filter_mem2_10 () from /usr/lib/libspeex.so.1
> (gdb) bt
> #0 0x40035bdb in filter_mem2_10 () from /usr/lib/libspeex.so.1
> #1 0x411c3264 in ?? ()
> #2 0x400139c0 in ?? ()
> #3 0x00000001 in ?? ()
> #4 0x00000000 in ?? ()
> #5 0x00000001 in ?? ()
> #6 0x00000000 in ?? ()
> #7 0x00000001 in ?? ()
> #8 0x411c32d8 in ?? ()
> #9 0x411c3264 in ?? ()
> #10 0x400296ff in ?? () from /usr/lib/libspeex.so.1
> #11 0x00000000 in ?? ()
> #12 0x400289b8 in ?? () from /usr/lib/libspeex.so.1
> #13 0x411c3294 in ?? ()
> #14 0x039ac0d0 in ?? ()
> #15 0x411c32d4 in ?? ()
> #16 0x40027000 in ?? ()
> #17 0x40029bdc in ?? () from /usr/lib/libspeex.so.1
> #18 0x00000000 in ?? ()
> #19 0x00000001 in ?? ()
> #20 0x40029028 in ?? () from /usr/lib/libspeex.so.1
> #21 0x40027000 in ?? ()
> #22 0x4000a1c6 in fixup () from /lib/ld-linux.so.2
> Previous frame inner to this frame (corrupt stack?)
--
Jean-Marc Valin
http://www.xiph.org/~jm/
LABORIUS
Universit? de Sherbrooke, Qu?bec, Canada
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Ceci est une partie de message
=?ISO-8859-1?Q?num=E9riquement?= =?ISO-8859-1?Q?_sign=E9e=2E?Url :
http://lists.xiph.org/pipermail/speex-dev/attachments/20040630/fdc88213/attachment.pgp