[Python-bugs-list] [ python-Bugs-528620 ] unicodeobject can coredump on exit

noreply@sourceforge.net noreply@sourceforge.net
Sat, 06 Apr 2002 17:37:26 -0800


Bugs item #528620, was opened at 2002-03-11 14:39
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=528620&group_id=5470

Category: Python Interpreter Core
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Rich Salz (rsalz)
Assigned to: M.-A. Lemburg (lemburg)
Summary: unicodeobject can coredump on exit

Initial Comment:
It looks like the internal unicode_empty object can be
destroyed before other unicode objects are destroyed.

    /* Convert to Unicode */
    if (len == 0) {
***     if (unicode_empty == NULL) goto onError;
        Py_INCREF(unicode_empty);
        v = (PyObject *)unicode_empty;
    }
    else
        v = PyUnicode_Decode(s, len, encoding, errors);

The line marked *** was added.  It prevents python from
segfaulting during its cleanup-and-exit phase.


----------------------------------------------------------------------

>Comment By: Rich Salz (rsalz)
Date: 2002-04-06 20:37

Message:
Logged In: YES 
user_id=36737

The original report described a test case; test/t3.py in the
ZSI package.  Following up on this, Dave Wallace has a short
example that crashes.  See his posting in to xml-sig, at
http://mail.python.org/pipermail/xml-sig/2002-April/007553.html


----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2002-04-06 02:31

Message:
Logged In: YES 
user_id=21627

Notice that unicode_empty is accessed from within
PyImport_Cleanup, which is currently run after PyUnicode_Fini.

I believe PyUnicode_Fini should be run *much* later, e.g.
after PyFloat_Fini.

----------------------------------------------------------------------

Comment By: Rich Salz (rsalz)
Date: 2002-03-12 21:29

Message:
Logged In: YES 
user_id=36737

Running python 2.1.1 against ZSI, for example test/t3.py segfaults on exit with the following as top of stack.
(gdb) bt
#0  0x0809365c in PyUnicode_FromEncodedObject () at eval.c:41
#1  0x0809352d in PyUnicode_FromObject () at eval.c:41
#2  0x0809714f in PyUnicode_Compare () at eval.c:41
#3  0x0808cb5d in PyObject_Unicode () at eval.c:41
#4  0x0808cf75 in PyObject_Compare () at eval.c:41
#5  0x0808d129 in PyObject_RichCompare () at eval.c:41
#6  0x08057361 in PyEval_EvalCode () at eval.c:41
#7  0x0805914f in PyEval_CallObjectWithKeywords () at eval.c:41
#8  0x08057829 in PyEval_EvalCode () at eval.c:41
#9  0x0805914f in PyEval_CallObjectWithKeywords () at eval.c:41
#10 0x08057829 in PyEval_EvalCode () at eval.c:41
#11 0x0805914f in PyEval_CallObjectWithKeywords () at eval.c:41
#12 0x08057829 in PyEval_EvalCode () at eval.c:41
#13 0x0805914f in PyEval_CallObjectWithKeywords () at eval.c:41
#14 0x08057829 in PyEval_EvalCode () at eval.c:41
#15 0x0805914f in PyEval_CallObjectWithKeywords () at eval.c:41
#16 0x08057829 in PyEval_EvalCode () at eval.c:41
#17 0x0805905b in PyEval_CallObjectWithKeywords () at eval.c:41
#18 0x08058c90 in PyEval_CallObjectWithKeywords () at eval.c:41
#19 0x08058f2b in PyEval_CallObjectWithKeywords () at eval.c:41
#20 0x08058c7d in PyEval_CallObjectWithKeywords () at eval.c:41
#21 0x08058b73 in PyEval_CallObjectWithKeywords () at eval.c:41
#22 0x0807c749 in PyInstance_New () at eval.c:41
---Type <return> to continue, or q <return> to quit---
#23 0x0808a0e4 in PyDict_New () at eval.c:41
#24 0x0808a3b6 in PyDict_SetItem () at eval.c:41
#25 0x0808bfc4 in _PyModule_Clear () at eval.c:41
#26 0x080654d6 in PyImport_Cleanup () at eval.c:41
#27 0x0806ae72 in Py_Finalize () at eval.c:41
#28 0x08051fae in Py_Main () at eval.c:41
#29 0x40080507 in __libc_start_main (main=0x8051a20 <main>, argc=2,
    ubp_av=0xbffff9c4, init=0x8050e7c <_init>, fini=0x809f070 <_fini>,
    rtld_fini=0x4000dc14 <_dl_fini>, stack_end=0xbffff9bc)
    at ../sysdeps/generic/libc-start.c:129
(gdb)


----------------------------------------------------------------------

Comment By: M.-A. Lemburg (lemburg)
Date: 2002-03-11 14:51

Message:
Logged In: YES 
user_id=38388

Provided you only use Unicode objects with the
Unicode implementation properly initialized, this
cannot happen. unicode_empty is kept alive between
calls to _PyUnicode_Init() and _PyUnicode_Fini().

If you are seeing a core dump in the location
you suggested, then it's likely that you have hit
a ref count bug somewhere.

In any case, I'd need an example to be able to say
whether this is indeed a bug in the core or in some
extension module.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=528620&group_id=5470