| msg9635 - (view) |
Author: Rich Salz (rsalz) |
Date: 2002-03-11 19:39 |
| 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. |
|
|
| msg9636 - (view) |
Author: Marc-Andre Lemburg (lemburg) *  |
Date: 2002-03-11 19:51 |
| 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. |
|
|
| msg9637 - (view) |
Author: Rich Salz (rsalz) |
Date: 2002-03-13 02:29 |
| 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 to continue, or q 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 , 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) |
|
|
| msg9638 - (view) |
Author: Martin v. Löwis (loewis) * |
Date: 2002-04-06 07:31 |
| 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. |
|
|
| msg9639 - (view) |
Author: Rich Salz (rsalz) |
Date: 2002-04-07 01:37 |
| 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 |
|
|
| msg9640 - (view) |
Author: Marc-Andre Lemburg (lemburg) * |
Date: 2002-04-08 08:22 |
| Logged In: YES user_id=38388 Moving PyUnicode_Fini down in the finalization list seems to help. Still, I'm afraid that if some Unicode objects are left stored in some lists or dictionaries, we may still see the problem (due to coercion of strings to Unicode). OTOH, strings are finalized before Unicode object now. Anyway, the test case works now after checkin of the fix proposed by Martin, so I'm closing the report. |
|
|
| msg9641 - (view) |
Author: Michael Hudson (mwh) |
Date: 2002-04-08 13:20 |
| Logged In: YES user_id=6656 So, do we want this in 221? I know you may have said in a checkin message... |
|
|
| msg9642 - (view) |
Author: Martin v. Löwis (loewis) * |
Date: 2002-04-08 13:38 |
| Logged In: YES user_id=21627 It's not a critical bug that is being fixed (a crash is critical, but it is a rare problem). OTOH, the fix seems reasonably straight-forward, and low risk (he says :-); so yes - if that is still possible, it should go into 2.2.1. Otherwise, it is a clear 2.2.2 candidate. |
|
|
| msg9643 - (view) |
Author: Marc-Andre Lemburg (lemburg) * |
Date: 2002-04-08 15:35 |
| Logged In: YES user_id=38388 I marked it as "2.2.1 candidate" group. IMHO, this should be done with all minor update candidates (I only found this group thingie today -- seems like a nice way to markup bug fix candidates). |
|
|