using BitBangDevice causes segmentation fault

Issue #25 resolved
Anonymous created an issue

The newly released 0.16.0 is now causing a Python segmentation fault as shown here: Program received signal SIGSEGV, Segmentation fault. 0x00007fffe42cdccd in libusb_set_auto_detach_kernel_driver () from /lib/x86_64-linux-gnu/libusb-1.0.so.0

0 0x00007fffe42cdccd in libusb_set_auto_detach_kernel_driver ()

from /lib/x86_64-linux-gnu/libusb-1.0.so.0

1 0x00007ffff4422adc in ffi_call_unix64 ()

from /usr/lib/x86_64-linux-gnu/libffi.so.6

2 0x00007ffff442240c in ffi_call ()

from /usr/lib/x86_64-linux-gnu/libffi.so.6

3 0x00007ffff46395fe in _call_function_pointer (argcount=2,

resmem=0x7fffffff99c0, restype=<optimized out>, atypes=<optimized out>, 
avalues=0x7fffffff99a0, 
pProc=0x7fffe42cdcc0 <libusb_set_auto_detach_kernel_driver>, flags=4353)
at /build/python2.7-t6d6Zr/python2.7-2.7.6/Modules/_ctypes/callproc.c:836

4 _ctypes_callproc (

pProc=pProc@entry=0x7fffe42cdcc0 <libusb_set_auto_detach_kernel_driver>, 
argtuple=argtuple@entry=0x7fffe591f1b8, flags=4353, 
argtypes=argtypes@entry=0x0, restype=restype@entry=0xbf6020, 
checker=checker@entry=0x0)
at /build/python2.7-t6d6Zr/python2.7-2.7.6/Modules/_ctypes/callproc.c:1183

5 0x00007ffff463af9e in PyCFuncPtr_call (self=<optimized out>,

inargs=<optimized out>, kwds=<optimized out>)
at /build/python2.7-t6d6Zr/python2.7-2.7.6/Modules/_ctypes/_ctypes.c:3923

The previous version 0.15.0 doesn't cause this same issue. We are using both 2 and 4 UART FTDI chips in our devices and toggling some GPIO pins connected to buttons on these devices and are observing the above error with the new version.

Comments (9)

  1. Ben Bass repo owner

    OK, thanks for the report. I've managed to duplicate it here on a 64 bit Ubuntu 16.04 machine here, so should hopefully be able to resolve fairly quickly.

    Initial indications are that the structure layout of the context object (ftdi_context_partial) doesn't match the actual library (i.e. seems pointers are only 32 bits even though library is 64 bit?)

    A quick workaround (other than downgrading the library) is to set auto_detach=False in the instantiation of the BitBangDevice.

    If I can't fix this in the next couple of days I'll release an update disabling this feature for now, but hopeful I should get a fix.

  2. Ben Bass repo owner

    OK, nothing to do with bits or not, just that old versions of the library don't have the same ftdi_context structure as later ones. Works fine against a newly build libftdi, but not against the standard Ubuntu 16.04 libftdi-dev package.

    So 0.16.0 (with auto-detach) is only working with libftdi 1.0+, and failing with 0.20.

    Would be useful to have the output of python -m pylibftdi.examples.info on your system, then try installing libftdi1-dev (assuming debian / ubuntu type system - note this is different to libftdi-dev which is typically the legacy 0.20 version) and see if it works then (and provide the info output again).

  3. Ryan Lindeman

    Thank you for looking into this. Here is the output of pylibftdi.examples.info.

    $ python -m pylibftdi.examples.info
    pylibftdi version     : 0.16.0
    libftdi version       : libftdi_version(major=0, minor=0, micro=0, version_str='< 1.0 - no ftdi_get_library_version()', snapshot_str='unknown')
    libftdi library name  : libftdi.so.1
    libusb version        : libusb_version(major=1, minor=0, micro=17, nano=10830, rc='', describe='http://libusbx.org')
    libusb library name   : libusb-1.0.so.0
    Python version        : 2.7.6
    OS platform           : Linux-4.4.0-87-generic-x86_64-with-Ubuntu-14.04-trusty
    

    The libftdi1-dev package doesn't exist for my platform (which is based on Ubuntu but has been customized by my employer). From what I can tell the libftdi-dev package is installed and is version 0.20-1ubuntu1.

  4. Ben Bass repo owner

    OK, good to note that it's 0.20, likely confirms the hypothesis around change in ftdi_context structure.

    I've updated to check the version of libftdi and use appropriate structure definitions, and re-released this on PyPI as 0.16.1.

    I've tested this on an Ubuntu system with libftdi 0.20 and 1.2.

  5. Ryan Lindeman

    This is still causing a crash from what I can tell, but its not in the same place as last time and I'm trying to prove that its still caused by pylibftdi as the crash appears to occur in libc.

  6. Ryan Lindeman

    From what I can tell, it seems to occur after I have opened a BitBangDevice closed it, then opened it again and closed it a 2nd time that the crash seems to occur. I believe it might be related to the destruction path of the BitBangDevice class.

  7. Ben Bass repo owner

    Seems that while it works fine when only a single instance of a Device / BitBangDevice is used in a process, opening and closing repeatedly in the same process can break.

    Seems to work well on libftdi 1.x+ but fail on 0.x.

    Tested with:

    from pylibftdi.bitbang import BitBangDevice
    for i in range(100):
      bb = BitBangDevice(auto_detach=True)
      bb.close()
      print(i)
    

    with auto_detach=False or libftdi 1.x+, this works fine; with auto_detach=True (or omitted) and libftdi 0.20 (and presumably other versions <1.0), this crashes after a few iterations.

    For now I've taken the solution of auto_detach being ignored if libftdi 0.x is in use.

    Issued in 0.16.1.1, hope it does the job. There's probably a way of supporting auto_detach properly for earlier libftdi, but I don't think I'll get there quickly, if at all, unless it's requested by people. In most environments I guess moving to more recent libftdi is possible, but I appreciate the issue around specific environment constraints.

    Running the tests is detailed at http://pylibftdi.readthedocs.io/en/0.15.0/how_to.html#how-do-i-run-the-tests

  8. Ryan Lindeman

    Thanks for the detailed information. I have confirmed that your fix is working in my situation. I appreciate the quick response in looking into this and fixing it.

  9. Log in to comment