Skip to content

ctypes unittest crashes with libffi 3.4.2 #88722

Closed

Description

@zan
mannequin
BPO 44556
Nosy @ned-deily, @dopplershift, @isuruf, @jakirkham, @h-vetinari, @erykoff
Superseder
  • bpo-45350: configure incorrectly ignores pkg-config information for libffi and Tcl/Tk in 3.10
  • Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.

    Show more details

    GitHub fields:

    assignee = None
    closed_at = <Date 2021-11-21.00:16:41.337>
    created_at = <Date 2021-07-03.01:27:44.161>
    labels = ['ctypes', '3.8', 'type-crash', '3.11']
    title = 'ctypes unittest crashes with libffi 3.4.2'
    updated_at = <Date 2021-11-21.00:16:41.330>
    user = 'https://bugs.python.org/zan'

    bugs.python.org fields:

    activity = <Date 2021-11-21.00:16:41.330>
    actor = 'ned.deily'
    assignee = 'none'
    closed = True
    closed_date = <Date 2021-11-21.00:16:41.337>
    closer = 'ned.deily'
    components = ['ctypes']
    creation = <Date 2021-07-03.01:27:44.161>
    creator = 'zan'
    dependencies = []
    files = []
    hgrepos = []
    issue_num = 44556
    keywords = []
    message_count = 5.0
    messages = ['396885', '406626', '406627', '406631', '406695']
    nosy_count = 7.0
    nosy_names = ['ned.deily', 'Ryan May', 'isuruf', 'jakirkham', 'h-vetinari', 'erykoff', 'zan']
    pr_nums = []
    priority = 'normal'
    resolution = 'duplicate'
    stage = 'resolved'
    status = 'closed'
    superseder = '45350'
    type = 'crash'
    url = 'https://bugs.python.org/issue44556'
    versions = ['Python 3.8', 'Python 3.11']

    Activity

    1. zan commented on Jul 3, 2021

      zanmannequin
      MannequinAuthor

      Running the unittests after upgrading libffi to latest version 3.4.2 and recompiling python, leads to several tests in Lib/ctypes/test/ to crash with Abort: trap 6. This does not happen with version 3.3 of libffi.

      Steps to reproduce:

      git clone https://github.com/libffi/libffi
      cd libffi
      autoreconf -fvi
      export CC=/usr/bin/clang
      ./configure
      make
      sudo make install # installs into /usr/local

      git clone https://github.com/python/CPython
      cd CPython
      export CC=/usr/bin/clang
      export CXX=/usr/bin/clang++
      export CPPFLAGS="-I/usr/local/include"
      export LDFLAGS="-L/usr/local/lib"
      ./configure --with-system-ffi
      make
      ./python Lib/ctypes/test/main.py -v

      ...
      test_callbacks (ctypes.test.test_as_parameter.AsParamPropertyWrapperTestCase) ... Abort trap: 6

      If I repeat the above steps with 'git checkout v3.3' in libffi, all tests in ctypes complete successfully.

      Tested with :

      • python 3.11 commit ec8759b0 (current master), also tried 3.8.11
      • libffi 3.4.2
      • macOS 11.4, Xcode 12.5.1
      • MacBook Air, x86_64, Intel Sky Lake, i5-8210Y
    2. added
      3.11only security fixes
      type-crashA hard crash of the interpreter, possibly with a core dump
      on Jul 3, 2021
    3. jakirkham commented on Nov 19, 2021

      jakirkhammannequin
      Mannequin

      We ran into the same issue in conda-forge ( conda-forge/python-feedstock#522 ).

      The problem is Apple also supplies their own libffi. However if the build scripts in CPython fail to find the user provided libffi, they end up pulling the headers from Apple's libffi, but the linker will link to the user provided libffi. IOW mashing these two incompatible libffi's together. As result one gets crashes like the one illustrated in this bug.

      In conda-forge, we are resolving this by forcing our pkg-config to be used to ensure we pick up the headers from our libffi as well as the libraries. Other users may be able to workaround this issue by explicitly setting LIBFFI_INCLUDE_DIR.

      That said, it would be preferable to have a clear way to specify the libffi used and ensure that Apple's one doesn't get accidentally pulled in. If this exists and we are just missing these details, some pointers to this effect would be very helpful.

    4. erykoff commented on Nov 19, 2021

      erykoffmannequin
      Mannequin

      To add a bit more color, I don't think you can explicitly set LIBFFI_INCLUDE_DIR, it's set by the configure script explicitly. The problem is that some time between python 3.9 and 3.10 the configure script has (at least in our system) failed to figure out the $PKG_CONFIG variable correctly. It should be set to the executable with the full path name, as is done with 3.9, but now it is set to just the executable name. When that happens the library location check fails.

    5. isuruf commented on Nov 20, 2021

      isurufmannequin
      Mannequin
    6. ned-deily commented on Nov 21, 2021

      @ned-deily
      Member

      Yes, this does appear to be a result of the problem described in bpo-45350. As noted there, the problem was caused by running autoreconf to regerenerate the ./configure script in an environment where pkg-config wasn't installed which caused some pkg-config code to be removed from ./configure. And, unfortunately, the ./configure script included with the v3.10.0 release still had that problem. You can copy an updated version from the current 3.10.0 branch or wait for 3.10.1 or you can try running autoreconf yourself in the source directory.

    7. transferred this issue fromon Apr 10, 2022
    Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

    Metadata

    Metadata

    Assignees

    No one assigned

      Labels

      3.11only security fixes3.8 (EOL)end of lifetopic-ctypestype-crashA hard crash of the interpreter, possibly with a core dump

      Projects

      No projects

        Milestone

        No milestone

        Relationships

        None yet

        Development

        No branches or pull requests

        Issue actions