Message149673
> So it seems unlikely to be the explanation.
Victor reproduced in on IRC, and it's indeed an overflow.
The problematic code is in readline_file:
"""
bigger = self->buf_size << 1;
if (bigger <= 0) { /* overflow */
PyErr_NoMemory();
return -1;
}
newbuf = (char *)realloc(self->buf, bigger);
if (!newbuf) {
PyErr_NoMemory();
return -1;
}
"""
self->buf_size is an int, which overflow pretty easily.
>>> 196 * 240000
47040000
>>> 196 * 240000 * 8 # assuming 8 bytes per float
376320000
>>> 2**31
2147483648
Hmmm... A byte is 8 bit, which gives:
>>> 196 * 240000 * 8 * 8
3010560000L
>>> 196 * 240000 * 8 * 8 > 2**31
True
Now, if it works on your box, it's probably due to the compiler optimizing the check away. Since `bigger` is cast to an unsigned 64-bit (size_t) when calling malloc(), it happens to work.
Maybe your distro doesn't build python with -fwrapv.
So, what do you suggest? Should we fix this (Py_ssize_t, overflow check before computation), as in #11564? |
|
Date |
User |
Action |
Args |
2011-12-17 16:21:30 | neologix | set | recipients:
+ neologix, mark.dickinson, pitrou, Ramchandra Apte, phillies |
2011-12-17 16:21:30 | neologix | set | messageid: <1324138890.47.0.844223294241.issue13555@psf.upfronthosting.co.za> |
2011-12-17 16:21:29 | neologix | link | issue13555 messages |
2011-12-17 16:21:29 | neologix | create | |
|