RetroSearch Browse

Tue Sep 16 12:31:20 EDT 2003 · https://mail.python.org/pipermail/python-dev/2003-September/038083.html

On Tue, 2003-09-16 at 12:12, Tim Peters wrote:
> [Jeremy Hylton]
> > I disabled the KEEPALIVE_SIZE_LIMIT, 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 (unicode_empty or single character
> >          objects) in-place is not allowed. Use PyUnicode_Resize()
> >          instead ! */
> >       if (unicode == unicode_empty ||
> >   	(unicode->length == 1 &&
> > ! 	 unicode->str[0] < 256 &&
> >   	 unicode_latin1[unicode->str[0]] == unicode)) {
> >           PyErr_SetString(PyExc_SystemError,
> >                           "can't resize shared unicode objects");
> > --- 130,142 ----
> >       /* Resizing shared object (unicode_empty or single character
> >          objects) in-place is not allowed. Use PyUnicode_Resize()
> >          instead ! */
> >       if (unicode == unicode_empty ||
> >   	(unicode->length == 1 &&
> > ! 	 unicode->str[0] < 256 && unicode->str[0] > 0 &&
> >   	 unicode_latin1[unicode->str[0]] == unicode)) {
> >           PyErr_SetString(PyExc_SystemError,
> >                           "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,

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 &&
>       unicode_latin1[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 <wink>).

I certainly don't understand the code yet.

Jeremy

Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Showing content from https://mail.python.org/pipermail/python-dev/2003-September/038083.html below:

[Python-Dev] RE: [Zope-Coders] core dump in Zope 2.7 test suite