gh-118331: Fix a couple of issues when list allocation fails

[mpage]

This fixes a couple of bugs that are triggered when list allocation fails. Specifically, when the list object is allocated
successfully, but allocation of the items array fails.

Use-after-free on the items array

We didn't set the items array pointer in the list object to NULL after freeing the items array. As a result, we could end up with a list object added to the free list that contained a pointer to an already-freed items array. A subsequent list allocation that successfully retrieved a list object from the free list but failed to allocate a new items would deallocate the
list object:

cpython/Objects/listobject.c

Lines 251 to 255 in bbf1979

	_PyListArray *array = list_allocate_array(size);
	if (array == NULL) {
	Py_DECREF(op);
	return PyErr_NoMemory();
	}

list_dealloc would then try to use the previously freed items array:

cpython/Objects/listobject.c

Lines 526 to 536 in bbf1979

	if (op->ob_item != NULL) {
	/* Do it backwards, for Christian Tismer.
	There's a simple test case where somehow this reduces
	thrashing when a *very* large list is created and
	immediately deleted. */
	i = Py_SIZE(op);
	while (--i >= 0) {
	Py_XDECREF(op->ob_item[i]);
	}
	free_list_items(op->ob_item, false);
	}

Incorrect stackpointer assertion

We check that either there is no Python code executing (frame is NULL) or the stack pointer for the current frame is set when executing _Py_Dealloc:

cpython/Objects/object.c

Lines 2987 to 2991 in bbf1979

	#ifndef Py_GIL_DISABLED
	/* This assertion doesn't hold for the free-threading build, as
	* PyStackRef_CLOSE_SPECIALIZED is not implemented */
	assert(tstate->current_frame == NULL || tstate->current_frame->stackpointer != NULL);
	#endif

I think the intent here is to catch places in the interpreter loop that escape due to decrefs where we aren't setting / clearing the stack pointer correctly (e.g. due to shortcomings in our analysis or escaping calls that are incorrectly marked as non-escaping). The assertion is overly conservative. It will catch all potentially escaping decrefs, but it will also catch decrefs that can never escape. In this case, _PyList_FromStackRefStealOnSuccess is, correctly, I think, marked as non-escaping. The only decref it can perform is on an exact list (not a subtype). However, it triggers this assertion.

There are a few options I can see for fixing this:

1. Get rid of the assertion.
2. Detect and don't assert when we encounter objects whose destructors cannot execute arbitrary code.
3. Mark _PyList_FromStackRefStealOnSuccess as escaping.

I went with (3) because it's correct, if pessimistic, and I don't think it'll impact performance too much. I think the assertion is worth keeping around and I'm not sure of a good way to do (2) generically. Happy to do something else if reviewers feel strongly otherwise.

• Issue: test_repl's test_no_memory: AssertionError: -6 not found in (1, 120) #118331

[colesbury]

LGTM.

I think going with (3), treating _PyList_FromStackRefStealOnSuccess as possibly escaping, makes sense for now. I don't expect it to impact performance given that we started treating PyStackRef_CLOSE as escaping without problems, and STORE_FAST is executed ~35x more frequently than BUILD_LIST.

[encukou]

This commit introduced a failure in --with-tracerefs builds:

======================================================================
FAIL: test_no_memory (test.test_list.ListTest.test_no_memory)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/encukou/dev/cpython/Lib/test/test_list.py", line 328, in test_no_memory
    self.assertIn("MemoryError", err.decode("utf-8"))
    ~~~~~~~~~~~~~^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
AssertionError: 'MemoryError' not found in 'Fatal Python error: _PyRefchain_Trace: _Py_hashtable_set() memory allocation failed\nPython runtime state: initialized\n\nCurrent thread 0x00007ff7cc547740 (most recent call first):\n  File "<string>", line 7 in <module>\n\nExtension modules: _testcapi (total: 1)\n'

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