SIGABRT in __ioctl() while waiting for /dev/binder response

Pre-requisites: ARMv7 device, Android platform 4.2.2.

Time to time I get SIGABRT upon interaction with a system service (a really buggy one) over a binder. The stack trace is as follows:

#00 pc 000170ac /system/lib/libc.so (__ioctl+8)
#01 pc 0002aa8d /system/lib/libc.so (ioctl+16)
#02 pc 00016ba1 /system/lib/libbinder.so (android::IPCThreadState::talkWithDriver(bool)+132)
#03 pc 0001709d /system/lib/libbinder.so (android::IPCThreadState::waitForResponse(android::Parcel*, int*)+44)
#04 pc 000172b7 /system/lib/libbinder.so (android::IPCThreadState::transact(int, unsigned int, android::Parcel const&, android::Parcel*, unsigned int)+114)
#05 pc 00014a3b /system/lib/libbinder.so (android::BpBinder::transact(unsigned int, android::Parcel const&, android::Parcel*, unsigned int)+34)

__ioctl resolves to the following assembly code:

000170a4 <__ioctl>:
    170a4:  e92d0090 push   {r4, r7}
    170a8:  e3a07036 mov    r7, #54 ; 0x36
    170ac:  ef000000 svc    0x00000000
    170b0:  e8bd0090 pop    {r4, r7}
    170b4:  e1b00000 movs   r0, r0
    170b8:  512fff1e bxpl   lr
    170bc:  ea0093a6 b  3bf5c 

The stack dump is triggered by signal 6 (SIGABRT), code -6 (SI_KILL), with a fault address like 0x304, 0x330, 0x33A (it differs time to time and I am not even sure whether it is really an address in any address space rather than an error code or a flag combination).

I have no idea what the signal might indicate, i.e. whether it is

• a driver error (but why is it relayed in such a strange way rather than over the return value?)
• an unintercepted driver fault (is that even possible without a kernel panic?);
• a kernel fault (outside the driver call and possibly unrelated to the driver);
• a broken interrupt vector (then why not SIGSEGV or SIGILL?);
• a result of SIGQUIT (Dalvik stack trace signal) received in supervisor mode.

In the last case, I take my amazement back and proceed to investigation of the blocking call freeze cause (deadlock in the called process?). Possibly, I can build a test application to reproduce this specific precondition but it will take time.

I found a number of similar-looking traces and bug reports around the web, indicating that the issue is not device or vendor specific (though possibly platform version specific).

The exact service being interacted with does not matter either.

P.S. logcat:

03-21 16:21:22.933   772   831 I InputDispatcher: Application is not responding: Window{41000dd8 u0 my.application.package/my.application.package.MyActivity}.  It has been 5008.3ms since event, 5005.7ms since wait started.  Reason: Waiting because the touched window has not finished processing the input events that were previously delivered to it.
03-21 16:21:22.943   772   831 I WindowManager: Input event dispatching timed out sending to my.application.package/my.application.package.MyActivity
03-21 16:21:23.163   772   831 I Process : Sending signal. PID: 16195 SIG: 3
03-21 16:21:23.163 16195 16200 I dalvikvm: threadid=3: reacting to signal 3
03-21 16:21:23.263 16195 16200 I dalvikvm: Wrote stack traces to '/data/anr/traces.txt'
03-21 16:21:23.273   772   831 E ActivityManager: ANR in my.application.package (my.application.package/my.application.package.MyActivity)
03-21 16:21:23.273   772   831 E ActivityManager: Reason: keyDispatchingTimedOut
03-21 16:21:23.273   772   831 E ActivityManager: Load: 0.0 / 0.0 / 0.0
03-21 16:21:23.273   772   831 E ActivityManager: CPU usage from 18140ms to 0ms ago:
-- CPU usage dump, nothing unusual --
03-21 16:21:23.273   772   831 E ActivityManager: 61% TOTAL: 33% user + 27% kernel + 0% iowait + 0.8% softirq
03-21 16:21:23.273   772   831 E ActivityManager: CPU usage from 5686369ms to 5686369ms ago with 0% awake:
03-21 16:21:23.273   772   831 E ActivityManager: 0% TOTAL: 0% user + 0% kernel
03-21 16:21:23.283   772   831 I Process : Sending signal. PID: 16195 SIG: 6
03-21 16:21:23.283 16195 16195 F libc    : Fatal signal 6 (SIGABRT) at 0x00000304 (code=0), thread 16195 (my.application.package)
-- and then the stack dump --