Hi,
Although the patch sent from MrMod will fix the problem, the actual
cause of this bug is not an integer overflow due to quite large input. I
want to make it clear.
The actual problem was quite simple: rate_flush() couldn't be called
more than once.
Look at the code:
1 static void rate_flush(rate_t * p)
2 {
3 fifo_t * fifo = &p->stages[p->num_stages].fifo;
4 uint64_t samples_out = p->samples_in / p->factor + .5;
5 size_t remaining = samples_out - p->samples_out;
6 sample_t * buff = calloc(1024, sizeof(*buff));
7
8 if (samples_out > p->samples_out) {
9 while ((size_t)fifo_occupancy(fifo) < remaining) {
10 rate_input(p, buff, (size_t) 1024);
11 rate_process(p);
12 }
13 fifo_trim_to(fifo, (int)remaining);
14 p->samples_in = 0;
15 }
16 free(buff);
17 }
At line 14, p->samples_in is cleared out to zero.
Therefore, next time you enter this function,
samples_out will become zero (at line 4), and samples_out -
p->samples_out will be negative (at line 5), but it's asigned to size_t
(unsigned integer type)....
You see? this was not expected at all.
This re-entrance to draining process could possibly be caused by larger
output than the buffer size (so sox cannot drain out whole remaining
samples at once).
------------------------------------------------------------------------------
LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial
Remotely access PCs and mobile devices and provide instant support
Improve your efficiency, and focus on delivering more value-add services
Discover what IT Professionals Know. Rescue delivers
http://p.sf.net/sfu/logmein_12329d2d
_______________________________________________
SoX-devel mailing list
SoX-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sox-devel
