Skip to content

Assertion failure when marshalling buffer object with exception being set #106287

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom
Open
chgnrdv opened this issue Jun 30, 2023 · 0 comments
Open

Assertion failure when marshalling buffer object with exception being set #106287

chgnrdv opened this issue Jun 30, 2023 · 0 comments
Labels
interpreter-core (Objects, Python, Grammar, and Parser dirs) type-crash A hard crash of the interpreter, possibly with a core dump

Comments

@chgnrdv
Copy link
Contributor

chgnrdv commented Jun 30, 2023 •
edited by bedevere-app bot
Loading

Bisected to 33d95c6. Appears only on debug builds, otherwise passes silently.

import marshal
x = ({int}, memoryview(b''))
marshal.dumps(x)

Output:

Fatal Python error: _Py_CheckSlotResult: Slot getbuffer of type memoryview succeeded with an exception set
Python runtime state: initialized
ValueError: unmarshallable object

Current thread 0x00007f213ea12280 (most recent call first):
  File "/home/radislav/repro.py", line 22 in <module>
Aborted (core dumped)

In w_complex_object, when PyMarshal_WriteObjectToString is called on set item that is unmarshallable (int type in this case), an exception gets set on current tstate. Attempt to marshal next tuple item that is memoryview instance leads to call to PyObject_GetBuffer with exception being set.

I'll submit a PR.

Linked PRs
@chgnrdv chgnrdv added the type-crash A hard crash of the interpreter, possibly with a core dump label Jun 30, 2023
@chgnrdv chgnrdv mentioned this issue Jun 30, 2023
Closed
@iritkatriel iritkatriel added the interpreter-core (Objects, Python, Grammar, and Parser dirs) label Nov 27, 2023
duaneg added a commit to duaneg/cpython that referenced this issue Apr 19, 2025
@duaneg
pythongh-106287: do not write objects after encountering an unmarshal…
407a473 
…ling error

Writing out an object may involve a slot lookup, which is not safe to do with
an exception raised. In debug mode an assertion failure will occur if this
happens. To avoid assertion failures, and possibly more subtle problems the
assertion is there to prevent, skip attempts to write an object after an error.

Note the unmarshal writing code won't raise an exception itself, however the
set writing code calls back into the top-level unmarshal function (see
pythongh-78903), which will check for failures and raises an exception. Once that
happens it is not safe to continue writing further objects.

Note also that some data may still be written even after an error occurred and
an exception has been raised: code objects write objects and longs, and the
latter will be written unconditionally, even if the former fails. This
shouldn't cause a problem as it is documented that "garbage data will also be
written to the file" in such cases, and the top-level function will handle and
report the error appropriately.

Add a test case to cover the various different object types which could trigger
such failures.
@bedevere-app bedevere-app bot mentioned this issue Apr 19, 2025
Open
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
interpreter-core (Objects, Python, Grammar, and Parser dirs) type-crash A hard crash of the interpreter, possibly with a core dump
Projects
None yet
Milestone
No milestone
Development

Successfully merging a pull request may close this issue.

gh-106287: Improve error handling in marshalling code chgnrdv/cpython
2 participants
@iritkatriel @chgnrdv