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

Jeremy Hylton jeremy at zope.com
Tue Sep 16 12:31:20 EDT 2003

On Tue, 2003-09-16 at 12:12, Tim Peters wrote:

[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?

Not a small test case, no, but I have boiled it down a bit. If you run the tests from a Zope checkout on the Zope-2_7-branch, you can provoke the crash with "test.py Template."

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 unicodelatin1[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,

It could also cause a segmentation violation depending on the value of the stack trash it reads. At least, that's what appears to be going wrong.

unicode->length == 1 && (unsigned int)unicode->str[0] < 256U &&_ _unicodelatin1[unicode->str[0]] == unicode would be a safe and correct guard.

That sounds better.

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 ).

I certainly don't understand the code yet.

Jeremy

More information about the Python-Dev mailing list