[Python-bugs-list] [ python-Bugs-482574 ] audioop.ratecv crashes

[noreply@sourceforge.net]

Bugs item #482574, was opened at 2001-11-16 10:56
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=482574&group_id=5470

Category: Extension Modules
Group: Python 2.1.1
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Matthias Baas (mbaas)
Assigned to: Tim Peters (tim_one)
Summary: audioop.ratecv crashes

Initial Comment:
The ratecv in the audioop module can crash under 
certain conditions. I'm using Python 2.1.1 under Win98 
SE and SuSE Linux 7.2

Here's a small program that demonstrates the problem. 
It creates an empty sample and tries to call ratecv.

##################################################
import audioop

nchannels = 2
width     = 2
framerate = 44100
nframes   = 107880
frames    = nchannels*width*nframes*chr(0)

newrate   = 37083
#newrate   = 35002

newfrag,state = audioop.ratecv(frames, width, 
nchannels, framerate, newrate, None)
##################################################

With newrate = 37083 it crashes and with 35002 it 
creates a MemoryError exception.

I already had a look into the source of audioop and 
found the problem to be in the following line inside 
audioop_ratecv():

str = PyString_FromStringAndSize(
   NULL, size * nchannels * (len * outrate + inrate - 
1) / inrate);

With big enough samples the second argument simply 
overflows. In the case of newrate=35002 the above 
expression yields a negative value and so an 
MemoryError exception occurs. With newrate=37083 the 
expression yields a positive value, but one that's 
much too small, so the remainder of the function 
writes into unallocated memory and crashes.



----------------------------------------------------------------------

>Comment By: Tim Peters (tim_one)
Date: 2001-12-04 22:11

Message:
Logged In: YES 
user_id=31435

This is fixed in Modules/audioop.c, revision 1.45.  The 
rates in your test case work fine now, and so does a 
newrate of 20 million; IOW, ratecv shouldn't suffer 
spurious overflows anymore, and if you pass absurdly large 
arguments no legitimate overflows should go undetected 
anymore either.

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2001-12-04 09:34

Message:
Logged In: YES 
user_id=6380

You're right. All it's calculating is a safe upper bound for
the output buffer size. Tim will fix it.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=482574&group_id=5470