RetroSearch Browse

Tue Sep 16 12:12:26 EDT 2003 · https://mail.python.org/pipermail/python-dev/2003-September/038081.html

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

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

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,

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

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

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

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