gh-118331: Fix test_list.ListTest.test_no_memory under trace refs build#130921
gh-118331: Fix test_list.ListTest.test_no_memory under trace refs build#130921mpage merged 1 commit intopython:mainfrom
test_list.ListTest.test_no_memory under trace refs build#130921Conversation
Memory allocation ends up failing in _PyRefchainTrace(), which produces different output. Assert that we don't segfault, which is the thing we want to test and is less brittle than checking output.
| """) | ||
| _, _, err = assert_python_failure("-c", code) | ||
| self.assertIn("MemoryError", err.decode("utf-8")) | ||
| rc, _, _ = assert_python_failure("-c", code) |
There was a problem hiding this comment.
Can we mark the test with @unittest.skipIf(support.Py_TRACE_REFS, 'cannot test Py_TRACE_REFS build') so that we don't run it under --with-trace-refs?
That's what we do in test_repl's test_no_memory (a different test with the same name).
Along those lines, I'm a bit confused because the PR refers to #118331, but that's a bug report for test_no_memory in test_repl.py not the test_no_memory in test_list.py.
There was a problem hiding this comment.
Can we mark the test with @unittest.skipIf(support.Py_TRACE_REFS, 'cannot test Py_TRACE_REFS build') so that we don't run it under --with-trace-refs?
Sure, I have a slight preference for this change since it's testing the thing we care about (not segfaulting) and works in both builds, but that's fine with me.
Along those lines, I'm a bit confused because the PR refers to #118331, but that's a bug report for test_no_memory in test_repl.py not the test_no_memory in test_list.py.
The PR that introduced the failure under tracerefs is linked to that issue so I figured it was fine to link to it as well. I'll create a new issue for this.
There was a problem hiding this comment.
Okay that makes sense. It doesn't need a new issue
Memory allocation ends up failing in _PyRefchainTrace(), which produces different output. Assert that we don't segfault, which is the thing we want to test and is less brittle than checking output.