Message296936
list_repr() is careful to fetch the list size on each iteration. However, it seems that the list size may be mutated just after by concurrent code, perhaps in _PyUnicodeWriter_WriteASCIIString() or Py_EnterRecursiveCall().
I witnessed this with a signal handler that shrank a list while printing a list from a loop in the main code path.
gdb excerpt:
Program received signal SIGSEGV, Segmentation fault.
0x00000000004a17d6 in PyObject_Repr (v=<unknown at remote 0x7ffff6044670>) at Objects/object.c:485
485 res = (*v->ob_type->tp_repr)(v);
(gdb) bt
#0 0x00000000004a17d6 in PyObject_Repr (v=<unknown at remote 0x7ffff6044670>) at Objects/object.c:485
#1 0x000000000047eef3 in list_repr (v=0x7ffff68e1d08) at Objects/listobject.c:373
[...]
(gdb) frame 1
#1 0x000000000047eef3 in list_repr (v=0x7ffff68e1d08) at Objects/listobject.c:373
373 s = PyObject_Repr(v->ob_item[i]);
(gdb) p v
$2 = (PyListObject *) 0x7ffff68e1d08
(gdb) p i
$3 = 19
(gdb) p v->ob_item[18]
$12 = <float at remote 0x7ffff6044628>
(gdb) p v->ob_item[19]
$13 = <unknown at remote 0x7ffff6044670>
(gdb) p ((PyVarObject*)(v))->ob_size
$14 = 19 |
|
Date |
User |
Action |
Args |
2017-06-26 19:56:59 | pitrou | set | recipients:
+ pitrou, rhettinger, vstinner, serhiy.storchaka |
2017-06-26 19:56:59 | pitrou | set | messageid: <1498507019.02.0.505462443219.issue30774@psf.upfronthosting.co.za> |
2017-06-26 19:56:58 | pitrou | link | issue30774 messages |
2017-06-26 19:56:58 | pitrou | create | |
|