Skip to content
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.

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

send errors in __releasebuffer__ to sys.unraisablehook #2886

Merged
merged 1 commit into from
Jan 19, 2023

Conversation

davidhewitt
Copy link
Member

I noticed that in the __releasebuffer__ implementation we currently diverge from documentation by allowing -> PyResult<()> return values, but they cause crashes later down the line.

e.g. without the other changes in this PR, the new test case would crash with the following message:

ValueError: oh dear

The above exception was the direct cause of the following exception:

Traceback (most recent call last):
  File "<string>", line 1, in <module>
SystemError: <class 'bytes'> returned a result with an exception set

After some deliberation I decided to allow -> PyResult<()> returns because:

  • it keeps the macro implementation and usage simpler
  • errors might be produced by the __releasebuffer__ internals anyway (e.g. due to PyCell locking, or invalid self type passed)

As a result, this PR cleans up the case discussed to send errors to sys.unraisablehook, and updates the documentation to be clearer on the allowed behaviour.

src/impl_/pyclass.rs Outdated Show resolved Hide resolved
@davidhewitt davidhewitt force-pushed the releasebuffer-cleanup branch from 6b31ed7 to 5f44d64 Compare January 18, 2023 20:53
@davidhewitt
Copy link
Member Author

Thanks as always for the thorough review! I've pushed a commit which should address all of those points and hopefully pass CI.

@davidhewitt davidhewitt force-pushed the releasebuffer-cleanup branch from 5f44d64 to 0bc9e49 Compare January 19, 2023 07:46
@davidhewitt
Copy link
Member Author

bors r=adamreichold

bors bot added a commit that referenced this pull request Jan 19, 2023
2886: send errors in `__releasebuffer__` to `sys.unraisablehook` r=adamreichold a=davidhewitt

I noticed that in the `__releasebuffer__` implementation we currently diverge from documentation by allowing `-> PyResult<()>` return values, but they cause crashes later down the line.

e.g. without the other changes in this PR, the new test case would crash with the following message:

```
ValueError: oh dear

The above exception was the direct cause of the following exception:

Traceback (most recent call last):
  File "<string>", line 1, in <module>
SystemError: <class 'bytes'> returned a result with an exception set
```

After some deliberation I decided to allow `-> PyResult<()>` returns because:
 - it keeps the macro implementation and usage simpler
 - errors might be produced by the `__releasebuffer__` internals anyway (e.g. due to `PyCell` locking, or invalid self type passed)

As a result, this PR cleans up the case discussed to send errors to `sys.unraisablehook`, and updates the documentation to be clearer on the allowed behaviour.

Co-authored-by: David Hewitt <1939362+davidhewitt@users.noreply.github.com>
@davidhewitt davidhewitt force-pushed the releasebuffer-cleanup branch from 0bc9e49 to 78c8ac1 Compare January 19, 2023 08:34
@bors
Copy link
Contributor

bors bot commented Jan 19, 2023

Canceled.

@davidhewitt
Copy link
Member Author

bors r+

bors bot added a commit that referenced this pull request Jan 19, 2023
2886: send errors in `__releasebuffer__` to `sys.unraisablehook` r=davidhewitt a=davidhewitt

I noticed that in the `__releasebuffer__` implementation we currently diverge from documentation by allowing `-> PyResult<()>` return values, but they cause crashes later down the line.

e.g. without the other changes in this PR, the new test case would crash with the following message:

```
ValueError: oh dear

The above exception was the direct cause of the following exception:

Traceback (most recent call last):
  File "<string>", line 1, in <module>
SystemError: <class 'bytes'> returned a result with an exception set
```

After some deliberation I decided to allow `-> PyResult<()>` returns because:
 - it keeps the macro implementation and usage simpler
 - errors might be produced by the `__releasebuffer__` internals anyway (e.g. due to `PyCell` locking, or invalid self type passed)

As a result, this PR cleans up the case discussed to send errors to `sys.unraisablehook`, and updates the documentation to be clearer on the allowed behaviour.

Co-authored-by: David Hewitt <1939362+davidhewitt@users.noreply.github.com>
@davidhewitt davidhewitt force-pushed the releasebuffer-cleanup branch from 78c8ac1 to 2748d92 Compare January 19, 2023 08:56
@bors
Copy link
Contributor

bors bot commented Jan 19, 2023

Canceled.

@davidhewitt
Copy link
Member Author

bors r=adamreichold

bors bot added a commit that referenced this pull request Jan 19, 2023
2886: send errors in `__releasebuffer__` to `sys.unraisablehook` r=adamreichold a=davidhewitt

I noticed that in the `__releasebuffer__` implementation we currently diverge from documentation by allowing `-> PyResult<()>` return values, but they cause crashes later down the line.

e.g. without the other changes in this PR, the new test case would crash with the following message:

```
ValueError: oh dear

The above exception was the direct cause of the following exception:

Traceback (most recent call last):
  File "<string>", line 1, in <module>
SystemError: <class 'bytes'> returned a result with an exception set
```

After some deliberation I decided to allow `-> PyResult<()>` returns because:
 - it keeps the macro implementation and usage simpler
 - errors might be produced by the `__releasebuffer__` internals anyway (e.g. due to `PyCell` locking, or invalid self type passed)

As a result, this PR cleans up the case discussed to send errors to `sys.unraisablehook`, and updates the documentation to be clearer on the allowed behaviour.

Co-authored-by: David Hewitt <1939362+davidhewitt@users.noreply.github.com>
@bors
Copy link
Contributor

bors bot commented Jan 19, 2023

Build failed:

@davidhewitt davidhewitt force-pushed the releasebuffer-cleanup branch from 2748d92 to 586fed2 Compare January 19, 2023 19:15
@davidhewitt
Copy link
Member Author

bors r=adamreichold

@bors
Copy link
Contributor

bors bot commented Jan 19, 2023

Build succeeded:

  • conclusion

@bors bors bot merged commit 0c9078a into PyO3:main Jan 19, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants