Changes by Terry J. Reedy tjre...@udel.edu:
--
status: open - closed
versions: -Python 2.4, Python 3.0
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue2620
___
Terry J. Reedy tjre...@udel.edu added the comment:
Brett, open and fixed are contradictory? for what version did you reopen this?
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue2620
___
Changes by R. David Murray rdmur...@bitdance.com:
--
nosy: +haypo
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue2620
___
___
Python-bugs-list
Terry J. Reedy tjre...@udel.edu added the comment:
Neal committed changes for 2.4,2.5, so I removed those.
3.0 is dead. Is this an issue for 3.1,3.2 or should it be closed?
--
nosy: +tjreedy
___
Python tracker rep...@bugs.python.org
Changes by Brett Cannon br...@python.org:
--
status: closed - open
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue2620
___
___
Python-bugs-list
Boya Sun boya@case.edu added the comment:
In Python/pyarena.c:
block_new(size_t size)
{
/* Allocate header and block as one unit.
ab_mem points just past header. */
block *b = (block *)malloc(sizeof(block) + size);
...
}
Should a check for overflow of
Changes by Brett Cannon [EMAIL PROTECTED]:
--
resolution: - fixed
___
Python tracker [EMAIL PROTECTED]
http://bugs.python.org/issue2620
___
___
Python-bugs-list mailing
Neal Norwitz [EMAIL PROTECTED] added the comment:
Committed revision 65261 for 2.5
Committed revision 65262 for 2.4.
--
status: open - closed
___
Python tracker [EMAIL PROTECTED]
http://bugs.python.org/issue2620
Marc-Andre Lemburg [EMAIL PROTECTED] added the comment:
The patch looks good to me.
___
Python tracker [EMAIL PROTECTED]
http://bugs.python.org/issue2620
___
___
Python-bugs-list
Gregory P. Smith [EMAIL PROTECTED] added the comment:
Commited to trunk. r65182.
This still needs backporting to release25-maint. (and release24-maint
if anyone is maintaining that)
--
keywords: +patch
versions: +Python 3.0 -Python 2.6
___
Python
Gregory P. Smith [EMAIL PROTECTED] added the comment:
diff up for review on http://codereview.appspot.com/2599
___
Python tracker [EMAIL PROTECTED]
http://bugs.python.org/issue2620
___
Gregory P. Smith [EMAIL PROTECTED] added the comment:
here's an updated patch. It makes PyMem_NEW and PyMem_RESIZE macros
always do explicit an overflow check before doing the multiplication.
Uses of the the macros have been cleaned up in the couple places I
noticed that would leak memory or
Changes by Gregory P. Smith [EMAIL PROTECTED]:
Removed file: http://bugs.python.org/file10027/issue2620-gps01-patch.txt
___
Python tracker [EMAIL PROTECTED]
http://bugs.python.org/issue2620
___
Marc-Andre Lemburg [EMAIL PROTECTED] added the comment:
On 32-bit platforms, it's probably best to add a size check. I don't
it's worth doing that on 64-bit platforms - overflows are rather
unlikely there.
__
Tracker [EMAIL PROTECTED]
Changes by Gregory P. Smith [EMAIL PROTECTED]:
--
assignee: - gregory.p.smith
versions: +Python 2.6
__
Tracker [EMAIL PROTECTED]
http://bugs.python.org/issue2620
__
___
Gregory P. Smith [EMAIL PROTECTED] added the comment:
Here's a patch that fixes this by making both Python's malloc and
realloc return NULL if (0 = size = PY_SSIZE_T_MAX).
A side effect of this is that strings on 32bit platforms can no longer
be allocated up to 2**31-1 in length as the malloc
Alexander Belopolsky [EMAIL PROTECTED] added the comment:
On Sun, Apr 13, 2008 at 11:12 PM, Gregory P. Smith
[EMAIL PROTECTED] wrote:
..
Here's a patch that fixes this by making both Python's malloc and
realloc return NULL if (0 = size = PY_SSIZE_T_MAX).
This will not solve the original
Justin Ferguson [EMAIL PROTECTED] added the comment:
i pulled the Macros out of pymem.h in a Vanille 2.5.2?
--
components: +None
versions: +Python 3.0
__
Tracker [EMAIL PROTECTED]
http://bugs.python.org/issue2620
__
Justin Ferguson [EMAIL PROTECTED] added the comment:
sorry didnt mean to change components and version-- I'm typing this from
my phone and its being uncooperative at the moment
--
components: +Library (Lib)
__
Tracker [EMAIL PROTECTED]
Justin Ferguson [EMAIL PROTECTED] added the comment:
just fixing the modifications my phone made earlier tonight
--
components: -Library (Lib), None
versions: -Python 3.0
__
Tracker [EMAIL PROTECTED]
http://bugs.python.org/issue2620
Justin Ferguson [EMAIL PROTECTED] added the comment:
Additionally-- the PyMem_NEW()/PyMem_New() macro's need to be fixed:
231 static
232 PyUnicodeObject *_PyUnicode_New(Py_ssize_t length)
233 {
234 register PyUnicodeObject *unicode;
235
236 /* Optimization for empty strings */
New submission from Justin Ferguson [EMAIL PROTECTED]:
174 static
175 int unicode_resize(register PyUnicodeObject *unicode,
176 Py_ssize_t length)
177 {
[...]
201
202 oldstr = unicode-str;
203 PyMem_RESIZE(unicode-str, Py_UNICODE, length + 1);
[...]
209
Changes by Justin Ferguson [EMAIL PROTECTED]:
Added file: http://bugs.python.org/file10012/python-2.5.2-unicode_resize-utf8.py
__
Tracker [EMAIL PROTECTED]
http://bugs.python.org/issue2620
__
Changes by Justin Ferguson [EMAIL PROTECTED]:
Added file:
http://bugs.python.org/file10013/python-2.5.2-unicode_resize-utf16.py
__
Tracker [EMAIL PROTECTED]
http://bugs.python.org/issue2620
__
Marc-Andre Lemburg [EMAIL PROTECTED] added the comment:
You are probably referring to 32-bit platforms. At least on 64-bit
platforms, there's no problem with your test cases:
# this is to get the unicode_freelist initialized
... # the length of the string must be = 9 to keep
... # unicode-str
Justin Ferguson [EMAIL PROTECTED] added the comment:
Yes, excuse me-- this should be 32-bit specific as I believe Python will
not let me get a string long enough to overflow the integer on 64-bit.
It's a big string, the only realistic scenario I can see is XML parsing
or similar.
theory$
Alexander Belopolsky [EMAIL PROTECTED] added the comment:
Note that in r61458 Neal replaced PyMem_RESIZE with a direct call to
PyMem_REALLOC thus eliminating integer overflow check even from the debug
builds.
--
nosy: +belopolsky, nnorwitz
__
Tracker
Alexander Belopolsky [EMAIL PROTECTED] added the comment:
Justin,
Where did you find the definition that you cited:
95 #define PyMem_RESIZE(p, type, n) \
96 ( assert((n) = PY_SIZE_MAX / sizeof(type)) , \
97 ( (p) = (type *) PyMem_REALLOC((p), (n) * sizeof(type)) ) )
?
Current
Changes by Gregory P. Smith [EMAIL PROTECTED]:
--
nosy: +gregory.p.smith
priority: - high
versions: +Python 2.4
__
Tracker [EMAIL PROTECTED]
http://bugs.python.org/issue2620
__
Alexander Belopolsky [EMAIL PROTECTED] added the comment:
The following simple change should be enough for this issue, but I would
consider implementing the overflow check in the PyMem_RESIZE and PyMem_NEW
macros and de-deprecate their use.
30 matches
Mail list logo
