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

Attaching reproducer script.  I don't know if that is worth fixing.

Is it possible to reproduce this issue without involving signal handlers?

Reproduced on 3.11.