Hi fellows,
I've been hit by a segfault recently in a binary wheel running on Python 3.7.3, but that worked fine on Python 3.7.5.
The code was compiled on Python 3.7.5 using manylinux1 Docker images and transformed in a manylinux1 wheel. The segmentation fault back trace did not make any sense, so I guessed it was an ABI change.
After running git bisect for a few hours, it turns out that the culprit is the following commit:
https://github.com/python/cpython/commit/8766cb74e186d3820db0a855ccd780d6d84...
From my understanding, that commit indeed changes the ABI by modifying the header file and the size of the PyGC_Head and breaks code compiled on Python >= 3.7.4 running on earlier Python 3.7 version.
I don't know if anything can be done about this now that it's done and released. It might be something we want to double check in the future. Having some kind of warning when doing backports could be worth it.
Cheers,
On Fri, 07 Feb 2020 14:59:19 +0100 Julien Danjou julien@danjou.info wrote:
Hi fellows,
I've been hit by a segfault recently in a binary wheel running on Python 3.7.3, but that worked fine on Python 3.7.5.
Can you clarify a bit? Was it with a single specific package, or is it reproducible with several Python packages? It would be good to know what's required exactly to hit this issue.
Regards
Antoine.
On Feb 7, 2020, at 13:33, Antoine Pitrou solipsis@pitrou.net wrote:
On Fri, 07 Feb 2020 14:59:19 +0100 Julien Danjou julien@danjou.info wrote:
I've been hit by a segfault recently in a binary wheel running on Python 3.7.3, but that worked fine on Python 3.7.5.
Can you clarify a bit? Was it with a single specific package, or is it reproducible with several Python packages? It would be good to know what's required exactly to hit this issue.
And, if you want action on this, please open a new issue about it on bugs.python.org.
Thanks!
-- Ned Deily nad@python.org -- []
On Fri, Feb 07 2020, Victor Stinner wrote:
You can find the rationale for this change in two issues:
First, it was a warning in clang ubsan (Undefined Behavior Sanitizer). Then ctypes started to crash when Python was compiled with clang. It means that compiling Python 3.7 with clang also had the issue.
The quick fix was to compile Python with -fmax-type-align=8 when clang was detected.
But it was a signal that something was wrong in Python on x86-64: Python didn't respect the x86-64 ABI.
Thanks for the detailed explanation!
I've been hit by a segfault recently in a binary wheel running on Python 3.7.3, but that worked fine on Python 3.7.5.
Do you know which wheel package caused the issue? Which part of Python caused the problem? Well, open a issue and try to provide as much information as possible ;-)
This happened in a custom module I wrote.
I've opened https://bugs.python.org/issue39599 with as many details as I can right now. It's a bit fuzzy even for me how to reproduce it with a minimal test case.
You can find the rationale for this change in two issues:
* https://bugs.python.org/issue27987 * https://bugs.python.org/issue36618
First, it was a warning in clang ubsan (Undefined Behavior Sanitizer). Then ctypes started to crash when Python was compiled with clang. It means that compiling Python 3.7 with clang also had the issue.
The quick fix was to compile Python with -fmax-type-align=8 when clang was detected.
But it was a signal that something was wrong in Python on x86-64: Python didn't respect the x86-64 ABI.
I've been hit by a segfault recently in a binary wheel running on Python 3.7.3, but that worked fine on Python 3.7.5.
Do you know which wheel package caused the issue? Which part of Python caused the problem? Well, open a issue and try to provide as much information as possible ;-)
Victor
Le ven. 7 févr. 2020 à 15:01, Julien Danjou julien@danjou.info a écrit :
Hi fellows,
I've been hit by a segfault recently in a binary wheel running on Python 3.7.3, but that worked fine on Python 3.7.5.
The code was compiled on Python 3.7.5 using manylinux1 Docker images and transformed in a manylinux1 wheel. The segmentation fault back trace did not make any sense, so I guessed it was an ABI change.
After running git bisect for a few hours, it turns out that the culprit is the following commit:
https://github.com/python/cpython/commit/8766cb74e186d3820db0a855ccd780d6d84...
From my understanding, that commit indeed changes the ABI by modifying the header file and the size of the PyGC_Head and breaks code compiled on Python >= 3.7.4 running on earlier Python 3.7 version.
I don't know if anything can be done about this now that it's done and released. It might be something we want to double check in the future. Having some kind of warning when doing backports could be worth it.
Cheers,
Julien Danjou // Free Software Hacker // https://julien.danjou.info _______________________________________________ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-leave@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/J2FGZPS5... Code of Conduct: http://python.org/psf/codeofconduct/
participants (4)
-
Antoine Pitrou -
Julien Danjou -
Ned Deily -
Victor Stinner