cpython 0.6.0 SIGSEGVs and test failures on s390x / System Z (big endian) #265
Comments
|
Thanks for the report! The |
|
I only have very limited access to s390x outside our automated build environment myself, but the error can also be reproduced in emulated s390x machines in QEMU. It's slow, but I can do that on my own machine. So if you need me to test some things, I can do that. But with stuff like mapping C bitfields to Rust, I'm way out of my depth ... maybe this could be a good question to ask on users.rust-lang.org? |
|
I think I figured out the problem while looking at a very similar failure in pyo3. There's bitshift and bitwise-and operations happening here: Since the byte order of that |
|
Both C and Rust use a I have no idea how to access a C bitfield in a portable manner from Rust. |
Python has three ways of obtaining an integer from an object: 1) directly calling `PyLong_AsLong` * uses `__index__` if available * in Python 3.9 and ealier, but not in 3.10, uses `__int__` if `__index__` is unavailable * throws `TypeError` if the conversion is not possible 2) using `PyNumber_Long` * uses `__int__` * may throw other exceptions like `ValueError`, e.g. when converting from empty string 3) using `PyNumber_Index` * always uses `__index__` with any Python version * throws `TypeError` if the conversion is not possible Previously, the behavior of rust-python was inconsistent: small integer types (e.g. `i32`) used approach 1; where as larger integer types (e.g. `i64`) used approach 2. This this commit, all integer types consistently use approach 3. This is a breaking change: extension methods declared with `arg: i32` parameters no longer accept Python floating-point values. This fixes `objects::num::test::float_to_*` test failures with Python 3.10-rc1 (#265).
Python has three ways of obtaining an integer from an object: 1) directly calling `PyLong_AsLong` * uses `__index__` if available * in Python 3.9 and ealier, but not in 3.10, uses `__int__` if `__index__` is unavailable * throws `TypeError` if the conversion is not possible 2) using `PyNumber_Long` * uses `__int__` * may throw other exceptions like `ValueError`, e.g. when converting from empty string 3) using `PyNumber_Index` * always uses `__index__` with any Python version * throws `TypeError` if the conversion is not possible Previously, the behavior of rust-cpython was inconsistent: small integer types (e.g. `i32`) used approach 1; where as larger integer types (e.g. `i64`) used approach 2. With this commit, all integer types consistently use approach 3. This is a breaking change: extension methods declared with `arg: i32` parameters no longer accept Python floating-point values. This fixes `objects::num::test::float_to_*` test failures with Python 3.10-rc1 (#265).
|
I was recently able to fix this in PyO3 with this PR: PyO3/pyo3#3015 You might be able to do something similar here. |
I tried updating the Fedora Linux packages for rust-cpython from version 0.5.2 to 0.6.0, but there are a lot of new issues with test failures on s390x architecture (the only big-endian architecture we have access to).
With python 3.9, there are these new test failures compared to 0.5.2:
With Python 3.10, there are additional failures, these two I have already investigated and traced back to changes in Python 3.10 itself:
objects::num::test::float_to_*unit tests fail since floats are no longer valid initializers for integers in Python 3.10:https://bugs.python.org/issue37999
https://docs.python.org/3.10/whatsnew/3.10.html#other-language-changes
src/objects/capsule.rsdoctests fail since the "private"unicodedata.ucnhash_CAPIsymbol was removed from Python 3.10:https://bugs.python.org/issue44418
These two tests fail too, but I do not get output from cargo:
Because it looks like the test threads / processes crash with segmentation faults:
For now, I think I'll have to skip running the test suite on s390x entirely.
The text was updated successfully, but these errors were encountered: