1. Python CFFI
  2. Untitled project
  3. cffi
  4. Issues
Issue #137 resolved

bus error running the tests on arm-linux-gnueabihf

Anonymous created an issue

seen with 0.8.1 and 2.7.6 on arm-linux-gnueabihf (Ubuntu trusty)


============================= test session starts ==============================
platform linux2 -- Python 2.7.6 -- pytest-2.5.1
collected 1091 items

c/test_c.py .........s.........................................................................Bus error
E: pybuild pybuild:256: test: plugin custom failed with: exit code=135: python2.7 -m pytest c/ testing/
dh_auto_test: pybuild --test -i python{version} -p 2.7 --dir . returned exit code 13
make[1]: *** [override_dh_auto_test] Error 13

this seems to be a regression compared to 0.7.2

Comments (7)

  1. Stefano Rivera
    • edited description

    Edited: Reformatted output. Also: armhf, not arm64.

    Interestingly, this happens in Ubuntu trusty, but not in Debian unstable, and they use the same libffi and Python. But slighlty different builds of gcc.

    Starting program: /usr/bin/python -m pytest -s ../../../c/ ../../../testing/ -k test_callback_receiving_tiny_struct
    [Thread debugging using libthread_db enabled]
    Using host libthread_db library "/lib/arm-linux-gnueabihf/libthread_db.so.1".
    Program received signal SIGILL, Illegal instruction.
    0xb6aed1e8 in ?? () from /lib/arm-linux-gnueabihf/libcrypto.so.1.0.0
    (gdb) cont
    ============================== test session starts ==============================
    platform linux2 -- Python 2.7.6 -- pytest-2.5.1
    collected 1091 items 
    Program received signal SIGBUS, Bus error.
    0xb6a6d99c in ffi_closure_VFP () from /usr/lib/arm-linux-gnueabihf/libffi.so.6
    (gdb) bt
    #0  0xb6a6d99c in ffi_closure_VFP ()
       from /usr/lib/arm-linux-gnueabihf/libffi.so.6
    #1  0xb6a6d944 in ffi_call_VFP () from /usr/lib/arm-linux-gnueabihf/libffi.so.6
    #2  0xb6a6de6c in ffi_call () from /usr/lib/arm-linux-gnueabihf/libffi.so.6
    #3  0xb6a82d60 in cdata_call (cd=0xb37e90, args=<optimized out>,
        kwds=<optimized out>) at c/_cffi_backend.c:2427
    (gdb) disas        
    Dump of assembler code for function ffi_closure_VFP:
       0xb6a6d998 <+0>:     vpush   {d0-d7}
    => 0xb6a6d99c <+4>:     add     r12, sp, #80    ; 0x50
       0xb6a6d9a0 <+8>:     push    {r12, lr}
       0xb6a6d9a4 <+12>:    add     r2, sp, #72     ; 0x48
       0xb6a6d9a8 <+16>:    add     r3, sp, #8
       0xb6a6d9ac <+20>:    sub     sp, sp, #72     ; 0x48
       0xb6a6d9b0 <+24>:    str     sp, [sp, #64]   ; 0x40
       0xb6a6d9b4 <+28>:    add     r1, sp, #64     ; 0x40
    (gdb) info registers
    r0             0xb6ff9fe0       3070205920
    r1             0xfc     252
    r2             0xb1f84c 11663436
    r3             0x273bbb00       658225920
    r4             0xb1f808 11663368
    r5             0x960e08 9833992
    r6             0x2762b0 2581168
    r7             0xbeffc5c0       3204433344
    r8             0x960e08 9833992
    r9             0x960e08 9833992
    r10            0x0      0
    r11            0xbeffc5a0       3204433312
    r12            0xb6ff9fe0       3070205920
    sp             0xbeffc54a       0xbeffc54a
    lr             0xb6a6d944       -1230579388
    pc             0xb6a6d99c       0xb6a6d99c <ffi_closure_VFP+4>
    cpsr           0x800f0010       -2146500592
  2. Armin Rigo

    So the vpush crashes? Why does it? On x86, the equivalent instruction can only crash in case of stack overflow, but here the sp register seems to be far from a page boundary. Is it on a machine which doesn't support floats in hardware? If so, that's libffi's fault for using vpush; I claim innocence here...

  3. Stefano Rivera

    Oh, I forgot the bit from the kernel ring buffer. It's an alignment error.

    [1972209.013819] Alignment trap: not handling instruction ed2d0b10 at [<b6a6d998>]
    [1972209.013921] Unhandled fault: alignment exception (0x811) at 0xbeffc50a

    The machine supports hardfloat:

    Processor       : ARMv7 Processor rev 4 (v7l)
    processor       : 0
    BogoMIPS        : 1694.10
    processor       : 1
    BogoMIPS        : 1694.10
    Features        : swp half thumb fastmult vfp edsp thumbee neon vfpv3 tls vfpv4 idiva idivt 
    CPU implementer : 0x41
    CPU architecture: 7
    CPU variant     : 0x0
    CPU part        : 0xc0f
    CPU revision    : 4
    Hardware        : SAMSUNG EXYNOS5 (Flattened Device Tree)
    Revision        : 0000
    Serial          : 0000000000000000
  4. Armin Rigo

    Ok, and indeed sp is at an unaligned address. I have no clue how it is possible. As far as I know it can only be libffi that sets it to this random number with custom assembler code. To me this looks like a bug in libffi in handling sub-word-sized structures (e.g. as a callback return value, like the test that crashes does).

  5. Log in to comment