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
testCreate
/testReserveMap
fails with Python 3.12
#123
Comments
I hit this on Fedora as well, and it's been there for a while. It seems to be an incompatible change in swig, or maybe in Python, or in the combination of the two somehow. Unfortunately, I don't know Python FFI well enough to fix it, and I don't really have time to learn. I've been hoping someone Python knowledgable would fix this :(. |
Fwiw, some more information here |
Thanks, @dgibson. To be clear, did you disable these specific tests on Fedora for now? I'm considering doing the same in Ubuntu/Debian. |
FWIW I tried the testcases with Python3.12 with newer swig 4.2.0 that claims to have support for py3.12 and it fails the same way. |
@sergiodj , sorry, I didn't mean the Fedora package of dtc - I'm not involved with that packaging. I meant that the upstream tests also fail running on my Fedora 39 system. |
This has now become a blocker for python 3.12 for alpine. Fix or workaround from Debian: https://sources.debian.org/patches/device-tree-compiler/1.7.0-2/fix-tests-for-Python3.12.patch/ |
Unfortunately not. I haven't had the time to continue debugging the issue, and meanwhile decided to skip the specific test. |
Hi,
This bug is affecting both Debian and Ubuntu. I spent some time investigating it and I believe it's caused by some Python 3.12 change that's affecting SWIG, but I'm not entirely sure.
The relevant log snippet follows:
The relevant code here seems to be:
dtc/pylibfdt/libfdt.i
Lines 1189 to 1197 in 3fbfdd0
When running with Python 3.11,
if (PyTuple_GET_SIZE(resultobj) == 0)
is true the first time we reach this point, which makes the list have the right number of elements. However, on Python 3.12 that check is never true (possibly becauseresultobj
has been initialized before and holds one element, but I couldn't find more details), which makes the final list have0
at the beginning.The text was updated successfully, but these errors were encountered: