[PD] mp3amp~ crash pd on ubuntu 12.04

[Nicolas Montgermont]

Hello all,

I have a problem here with mp3amp. It crashes pd when connecting to a 
stream.
I can't use ogg for special reasons. Regarding the crash log, do you 
have an idea of the origin of the problem?
the config is :
pd : 0.43.2
mp3amp & unauthorised from svn (1 week ago)
ubuntu: 12.04
libmp3lame : 3.99.3+repack1-1
Is this an incompatibility between actual mp3lame and mp3amp? I know it 
is building against specific headers located in the unauthorized directory.
OTOH mp3cast~ seems to work well.

Here is the log of the crash using valgrind:
Best
n
--
mp3amp~: connecting to http:/27.112.111.91:8000/infinite_stream_loop.mp3
mp3amp~: connected  : socket opened
mp3amp~: select done
mp3amp~: send done
mp3amp~ : received 251 bytes at 0
mp3amp~: IceCast server detected
mp3amp~: connected to http://27.112.111.91:8000/infinite_stream_loop.mp3
==8884== Thread 1:
==8884== Invalid write of size 4
==8884==    at 0x530F03D: decode_header (in 
/usr/lib/i386-linux-gnu/libmp3lame.so.0.0.0)
==8884==    by 0x5363005: mp3amp_perform (mp3amp~.c:474)
==8884==    by 0x80D0A86: dsp_tick (in /usr/local/bin/pd)
==8884==    by 0x80BBE58: sched_tick (in /usr/local/bin/pd)
==8884==    by 0x80BCE00: m_mainloop (in /usr/local/bin/pd)
==8884==    by 0x805724A: main (in /usr/local/bin/pd)
==8884==  Address 0xfffb92d9 is not stack'd, malloc'd or (recently) free'd
==8884==
==8884==
==8884== Process terminating with default action of signal 11 (SIGSEGV)
==8884==  Access not within mapped region at address 0xFFFB92D9
==8884==    at 0x530F03D: decode_header (in 
/usr/lib/i386-linux-gnu/libmp3lame.so.0.0.0)
==8884==    by 0x5363005: mp3amp_perform (mp3amp~.c:474)
==8884==    by 0x80D0A86: dsp_tick (in /usr/local/bin/pd)
==8884==    by 0x80BBE58: sched_tick (in /usr/local/bin/pd)
==8884==    by 0x80BCE00: m_mainloop (in /usr/local/bin/pd)
==8884==    by 0x805724A: main (in /usr/local/bin/pd)
==8884==  If you believe this happened as a result of a stack
==8884==  overflow in your program's main thread (unlikely but
==8884==  possible), you can try to increase the size of the
==8884==  main thread stack using the --main-stacksize= flag.
==8884==  The main thread stack size used in this run was 8388608.
==8884==
==8884== HEAP SUMMARY:
==8884==     in use at exit: 20,022,264 bytes in 5,910 blocks
==8884==   total heap usage: 20,397 allocs, 14,487 frees, 24,795,334 
bytes allocated
==8884==
==8884== LEAK SUMMARY:
==8884==    definitely lost: 116 bytes in 6 blocks
==8884==    indirectly lost: 0 bytes in 0 blocks
==8884==      possibly lost: 288 bytes in 2 blocks
==8884==    still reachable: 20,021,860 bytes in 5,902 blocks
==8884==         suppressed: 0 bytes in 0 blocks
==8884== Rerun with --leak-check=full to see details of leaked memory
==8884==
==8884== For counts of detected and suppressed errors, rerun with: -v
==8884== Use --track-origins=yes to see where uninitialised values come from
==8884== ERROR SUMMARY: 173787 errors from 25 contexts (suppressed: 0 
from 0)
Processus arrêté

-- 
http://nim.on.free.fr