Jan 27, 2026 · Jan 27, 2026 · Jan 28, 2026 · Jan 28, 2026 · Jan 27, 2026 · Jan 28, 2026
diff --git a/Lib/test/_test_multiprocessing.py b/Lib/test/_test_multiprocessing.py
                    "resource_tracker: There appear to be 1 leaked "
                    "shared_memory objects to clean up at shutdown", err)

    def test_shared_memory_slice_assignment_no_crash(self):
        from multiprocessing import shared_memory
        shm = shared_memory.SharedMemory(create=True, size=10)
        mv = shm.buf
        shm.close()
        shm.unlink()
        with self.assertRaises((BufferError, ValueError)):
            mv[:5] = b'hello'

    @unittest.skipIf(os.name != "posix", "resource_tracker is posix only")
    @resource_tracker_format_subtests
    def test_shared_memory_untracking(self):
diff --git a/Misc/NEWS.d/next/Core_and_Builtins/2026-01-27-23-35-19.gh-issue-144281.IiakEV.rst b/Misc/NEWS.d/next/Core_and_Builtins/2026-01-27-23-35-19.gh-issue-144281.IiakEV.rst
 Fix a possible interpreter crash during memoryview slice assignment when the
 underlying buffer is backed by shared memory.
diff --git a/Objects/memoryobject.c b/Objects/memoryobject.c

 CHECK_RELEASED_INT(self);

 if (view->buf==NULL) {
 PyErr_SetString(PyExc_BufferError,"memoryview: underlying buffer is no longer valid");
 return-1;
    }

 fmt=adjust_fmt(view);
 if (fmt==NULL)
 return-1;
Original file line number	Diff line number	Diff line change
Expand Up		@@ -4932,6 +4932,15 @@ def test_shared_memory_cleaned_after_process_termination(self):
		"resource_tracker: There appear to be 1 leaked "
		"shared_memory objects to clean up at shutdown", err)

		def test_shared_memory_slice_assignment_no_crash(self):
VanshAgarwal24036 marked this conversation as resolved. Show resolvedHide resolved
		from multiprocessing import shared_memory
		shm = shared_memory.SharedMemory(create=True, size=10)
		mv = shm.buf
		shm.close()
		shm.unlink()
		with self.assertRaises((BufferError, ValueError)):
		mv[:5] = b'hello'

		@unittest.skipIf(os.name != "posix", "resource_tracker is posix only")
		@resource_tracker_format_subtests
		def test_shared_memory_untracking(self):
Expand Down
Original file line number	Diff line number	Diff line change
		@@ -0,0 +1,2 @@
		Fix a possible interpreter crash during memoryview slice assignment when the
		underlying buffer is backed by shared memory.
Original file line number	Diff line number	Diff line change
Expand Up		@@ -2656,6 +2656,11 @@ memory_ass_sub(PyObject _self, PyObject key, PyObject *value)

		CHECK_RELEASED_INT(self);

		if (view->buf==NULL) {
Copy link Contributor duanegJan 27, 2026 Choose a reason for hiding this comment The reason will be displayed to describe this comment to others.Learn more. It is not clear this is a necessary or sufficient fix without a valid specific trigger. Copy link ContributorAuthor VanshAgarwal24036Jan 28, 2026 Choose a reason for hiding this comment The reason will be displayed to describe this comment to others.Learn more. I’ve updated the test that should also make the need for the view->buf NULL check clearer. Copy link Contributor duanegJan 28, 2026 Choose a reason for hiding this comment The reason will be displayed to describe this comment to others.Learn more. The issue is moot since this has been closed, but I'm afraid this still wouldn't have been useful. Your fix is unrelated to the test; it passes with or without it. It is good practice to always run your test scripts against affected versions, to confirm it reproduces the bug. Without that you don't know the testworks. Also note the bug in the OP is a`SIGBUS`, a fatal signal. It is completely expected that invalid operations like this raise exceptions, but it shouldn't be possible to trigger a fatal signal via the public API^{-ish. Terms and conditions apply. Offer void whenctypes ormmap orgc or various other low-level power tools.}
		PyErr_SetString(PyExc_BufferError,"memoryview: underlying buffer is no longer valid");
		return-1;
		}

		fmt=adjust_fmt(view);
		if (fmt==NULL)
		return-1;
Expand Down