summaryrefslogtreecommitdiffstats
path: root/Modules/cStringIO.c
diff options
context:
space:
mode:
authorAmaury Forgeot d'Arc <amauryfa@gmail.com>2008-02-16 14:34:57 (GMT)
committerAmaury Forgeot d'Arc <amauryfa@gmail.com>2008-02-16 14:34:57 (GMT)
commit588ff93f1383436694e26c962528291913012296 (patch)
tree21b15b95feb36e0042c50be5ff650e002c66d30e /Modules/cStringIO.c
parent943321d586f3ce1d084995c66fe85137d8b8ebf8 (diff)
downloadcpython-588ff93f1383436694e26c962528291913012296.zip
cpython-588ff93f1383436694e26c962528291913012296.tar.gz
cpython-588ff93f1383436694e26c962528291913012296.tar.bz2
Crashers of the day: Py_CLEAR must be used when there is a chance that the
function can be called recursively. This was discussed in issue1020188. In python codebase, all occurrences of Py_[X]DECREF(xxx->yyy) are suspect, except when they appear in tp_new or tp_dealloc functions, or when the member cannot be of a user-defined class. Note that tp_init is not safe. I do have a (crashing) example for every changed line. Is it worth adding them to the test suite? Example: class SpecialStr(str): def __del__(self): s.close() import cStringIO s = cStringIO.StringIO(SpecialStr("text")) s.close() # Segfault
Diffstat (limited to 'Modules/cStringIO.c')
-rw-r--r--Modules/cStringIO.c3
1 files changed, 1 insertions, 2 deletions
diff --git a/Modules/cStringIO.c b/Modules/cStringIO.c
index 3529047..139a4a8 100644
--- a/Modules/cStringIO.c
+++ b/Modules/cStringIO.c
@@ -575,8 +575,7 @@ newOobject(int size) {
static PyObject *
I_close(Iobject *self, PyObject *unused) {
- Py_XDECREF(self->pbuf);
- self->pbuf = NULL;
+ Py_CLEAR(self->pbuf);
self->buf = NULL;
self->pos = self->string_size = 0;