Bug#635321: soundtouch: memory corruption when using bpmdetect

[Olli Parviainen]

On 31.7.2011 20:03, Alessio Treglia wrote:
> Hi Olli!
>
> On Debian we have encountered a memory corruption in soundtouch 1.6.0
> and I've filed a bug report in the project's tracker [1]; I've also
> attached a complete backtrace there.
>
> I hope to hear from you soon, thanks in advance for any reply.
>
>
> [1] http://bit.ly/pi1Cnw
>

Hello Alessio,

I looked at this issue. The log pinpoint error onto a dynamic memory 
allocation in constructor of BPMDetect object. I took a Subversion diff 
to see what's changed in BPM detection routines between SoundTouch 1.5.0 
and 1.6.0 that could cause illegal write to dynamically allocated 
memory, but there aren't such obvious logic changes between 1.5.0 and 1.6.0.

Further, if I understand the glibc memory error detection message 
correctly, upon attempting dynamic memory allocation with "new" on line 
147 of BPMDetect.cpp, the glibc malloc() detects that the dynamic memory 
heap has _already_ got corrupted upon malloc is being invoked at that 
point. Thus the problem obviously lays outside BPMDetect.cpp routine so 
that the bug activates already prior to instantiating the BPMDetect 
object, yet invoking the BPMDetect constructor eventually causes glibc 
to detect the recently occurred heap corruption.

This issue seems related with a bpm plug-in that uses SoundTouch BPM 
detection routines, and issue description mentions that problem doesn't 
reproduce with older version of SoundTouch. Can you confirm if using 
older version of SoundTouch means using also older version of the 
bpm.dll framework code, because studying what has changed in the hosting 
plug-in code would be next obvious step to debug the problem?

Also, can you reproduce this problem by using such debug compilation of 
SoundTouch that has assert() checks active, because the asserts can be 
helpful in detecting the root cause?

best regards, Olli Parviainen