FS#64169 - [python] Segfault on ctypes import

Attached to Project: Arch Linux
Opened by Oliver (Interweaver) - Friday, 18 October 2019, 13:58 GMT
Last edited by Antonio Rojas (arojas) - Sunday, 05 January 2020, 21:07 GMT
Task Type Bug Report
Category Packages: Extra
Status Closed
Assigned To No-one
Architecture x86_64
Severity High
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 0
Private No

Details

Importing ctypes with Python 3.7.4-2 immediately core dumps on my machine, I cannot say when this started as I'm fairly new to Arch and haven't been using the module for some time.

Here is python's relevant debug output:

$ python -v -c 'import ctypes'

(...)
# /usr/lib/python3.7/ctypes/__pycache__/__init__.cpython-37.pyc matches /usr/lib/python3.7/ctypes/__init__.py
# code object from '/usr/lib/python3.7/ctypes/__pycache__/__init__.cpython-37.pyc'
# extension module '_ctypes' loaded from '/usr/lib/python3.7/lib-dynload/_ctypes.cpython-37m-x86_64-linux-gnu.so'
# extension module '_ctypes' executed from '/usr/lib/python3.7/lib-dynload/_ctypes.cpython-37m-x86_64-linu x-gnu.so'
import '_ctypes' # <_frozen_importlib_external.ExtensionFileLoader object at 0x7f4ebb44ac10>
# /usr/lib/python3.7/__pycache__/struct.cpython-37.pyc matches /usr/lib/python3.7/struct.py
# code object from '/usr/lib/python3.7/__pycache__/struct.cpython-37.pyc'
# extension module '_struct' loaded from '/usr/lib/python3.7/lib-dynload/_struct.cpython-37m-x86_64-linux-gnu.so'
# extension module '_struct' executed from '/usr/lib/python3.7/lib-dynload/_struct.cpython-37m-x86_64-linux-gnu.so'
import '_struct' # <_frozen_importlib_external.ExtensionFileLoader object at 0x7f4ebb44cb50>
import 'struct' # <_frozen_importlib_external.SourceFileLoader object at 0x7f4ebb44c710>
# /usr/lib/python3.7/ctypes/__pycache__/_endian.cpython-37.pyc matches /usr/lib/python3.7/ctypes/_endian.py
# code object from '/usr/lib/python3.7/ctypes/__pycache__/_endian.cpython-37.pyc'
import 'ctypes._endian' # <_frozen_importlib_external.SourceFileLoader object at 0x7f4ebb2eb090>

Segmentation fault (core dumped)


See attachment for what I'll have in syslog. It's not an interpreter-only problem, ctypes generally is unusable. My libffi is at 3.2.1-3.
   stacktrace.txt (5.7 KiB)
This task depends upon

Closed by  Antonio Rojas (arojas)
Sunday, 05 January 2020, 21:07 GMT
Reason for closing:  Works for me
Comment by Oliver (Interweaver) - Saturday, 19 October 2019, 07:01 GMT
Sorry, I've just seen Python is already tagged out-of-date. Maybe an upgrade will fix this, so far at least reinstalling python or libffi made no difference. Also I can still pull in _ctypes, but any subsequent dlopen makes python puke, trace being very similar only then dying in libdl instead. Probably some versioning mismatch in the compiled modules, if not a local issue.
Comment by Oliver (Interweaver) - Sunday, 20 October 2019, 11:04 GMT
Solved: ctypes apparently depends hard on mpdecimal, I didn't know that and it's listed optional, so I wasn't at first thinking of missing deps. Requesting closure.
Comment by Chris Billington (chrisjbillington) - Wednesday, 30 October 2019, 15:44 GMT
I don't have mpdecimal installed and ctypes doesn't segfault on my machine. Is the dependency specific to your machine?

I would think that any hard dependency of `ctypes` should be included as such in the `python` package, if it is not I would consider that a bug.
Comment by Oliver (Interweaver) - Sunday, 03 November 2019, 06:38 GMT
There's nothing wrong with the package, I could not reproduce on other installations either. Meanwhile ctypes still working on this one too, even after removing mpd again, all I did was a reboot. Some local hiccup, or perhaps I had something resident that was upgraded on disk, should have checked this. Thanks for replying.

Loading...