[Python-Dev] cpython: Issue #18408: Fix PyUnicode_AsUTF8AndSize(), raise MemoryError exception on (original) (raw)

Georg Brandl g.brandl at gmx.net
Tue Oct 29 13:47:47 CET 2013

Gesendet: Dienstag, 29. Oktober 2013 um 10:54 Uhr Von: "Victor Stinner" <victor.stinner at gmail.com> An: "Georg Brandl" <g.brandl at gmx.net> Cc: "Python Dev" <python-dev at python.org> Betreff: Re: [Python-Dev] cpython: Issue #18408: Fix PyUnicodeAsUTF8AndSize(), raise MemoryError exception on

2013/10/29 Georg Brandl <g.brandl at gmx.net>: >> diff --git a/Objects/unicodeobject.c b/Objects/unicodeobject.c >> --- a/Objects/unicodeobject.c >> +++ b/Objects/unicodeobject.c >> @@ -3766,6 +3766,7 @@ >> return NULL; >> PyUnicodeUTF8(unicode) = PyObjectMALLOC(PyBytesGETSIZE(bytes) + 1); >> if (PyUnicodeUTF8(unicode) == NULL) { >> + PyErrNoMemory(); >> PyDECREF(bytes); >> return NULL; >> } > > Shouldn't this (and related commits from #18408) have been committed to the 3.3 > branch? All changes of #18408 "should" be backported, but I don't plan to backport them. It is not trivial to backport them. Nobody complained before (memory allocation failure are usually bad handled anyway, it will crash later if it does not crash here). And I'm not 100% confident that these changes would not break anything.

OK, that's a good enough reason, if it's "only" no-memory-related errors.

Examples of possible regression:

- PyEvalGetLocals() now raises an exception in case of an error. This change "should" not break anything, because callers were already raising an exception when PyEvalGetLocals() returns NULL. The builtin locals() function was not raising an exception in case of error, but it's probably because it is very unlikely that the function is called without any frame (PyEvalGetFrame(); returns NULL). - many functions now fail with an assertion error when they are called with an exception set (assert(!PyErrOccurred());) because they may replace the exception without noticing the caller - I tried to check reference counters, but I may have introduce a regression leak in the error handling code If there is really a regression, I prefer to limit it to the new version, not to a stable version. Note: I'm not saying that I'm 0% confident in my changes :-)

And I certainly think they have a better than 0% chance of being correct ;)

Georg

More information about the Python-Dev mailing list