[Python-Dev] RE: [Zope-Coders] core dump in Zope 2.7 test suite (original) (raw)

Tim Peters tim at zope.com
Tue Sep 16 12:12:26 EDT 2003

[Jeremy Hylton]

I disabled the KEEPALIVESIZELIMIT, as you suggested, and that also fixed the problem.

We don't know why, though, nor do we have a small test case, right?

The comment describe the code is really unnerving:

/* Limit for the Unicode object free list stay alive optimization. ... Note: This is an experimental feature ! If you get core dumps when using Unicode objects, turn this feature off. */ Why was this experimental feature released with Python if it causes core dumps?

Good question .

Going back to an earlier msg:

Index: unicodeobject.c =================================================================== RCS file: /cvsroot/python/python/dist/src/Objects/unicodeobject.c,v retrieving revision 2.196 diff -c -r2.196 unicodeobject.c *** unicodeobject.c 16 Sep 2003 03:41:45 -0000 2.196 --- unicodeobject.c 16 Sep 2003 03:55:53 -0000 *************** *** 130,138 **** /* Resizing shared object (unicodeempty or single character objects) in-place is not allowed. Use PyUnicodeResize() instead ! */ if (unicode == unicodeempty || (unicode->length == 1 && ! unicode->str[0] < 256 &&_ _unicodelatin1[unicode->str[0]] == unicode)) { PyErrSetString(PyExcSystemError, "can't resize shared unicode objects"); --- 130,142 ---- /* Resizing shared object (unicodeempty or single character objects) in-place is not allowed. Use PyUnicodeResize() instead ! */ if (unicode == unicodeempty || (unicode->length == 1 && ! unicode->str[0] < 256 && unicode->str[0] > 0 && unicodelatin1[unicode->str[0]] == unicode)) { PyErrSetString(PyExcSystemError, "can't resize shared unicode objects");

Belaboring the obvious, if unicode->str[0] is really heap trash at this point, there's no safe test.

On second thought, the test could be correct even if it does read up heap trash: the

unicode_latin1[unicode->str[0]] == unicode

part is a very strong condition. If str[0] does contain heap trash, it can't pass, but it could cause Purify (etc) to whine about reading uninitialized memory. If we don't care about that,

 unicode->length == 1 &&
  (unsigned int)unicode->str[0] < 256U &&
  unicode_latin1[unicode->str[0]] == unicode

would be a safe and correct guard.

Still, it doesn't look to me like the code expected that str could contain uninitialized heap trash at this point, so I'd like someone who thinks they understand this code to think about how that could happen (it apparently is happening, so "beats me" isn't good enough ).

More information about the Python-Dev mailing list