SIGABRT в __ioctl() во время ожидания ответа /dev/binder
Пререквизиты: устройство ARMv7, платформа Android 4.2.2.
Время от времени я получаю SIGABRT при взаимодействии с системным сервисом (действительно с ошибками) через связующее. Трассировка стека выглядит следующим образом:
#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 разрешает следующий код сборки:
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
Дамп стека инициируется сигналом 6 (SIGABRT), код -6 (SI_KILL), с адресом ошибки, таким как 0x304, 0x330, 0x33A (время от времени отличается, и я даже не уверен, действительно ли это адрес в каком-либо адресе пробел, а не код ошибки или комбинация флагов).
Я понятия не имею, на что может указывать сигнал, т.е.
- ошибка драйвера (но почему она передается таким странным образом, а не через возвращаемое значение?)
- не перехваченная ошибка драйвера (это возможно даже без паники ядра?);
- ошибка ядра (вне вызова драйвера и, возможно, не связанная с драйвером);
- сломанный вектор прерывания (тогда почему не SIGSEGV или SIGILL?);
- результат SIGQUIT (сигнал трассировки стека Dalvik), полученный в режиме супервизора.
В последнем случае я забираю свое изумление и приступаю к расследованию причины замораживания блокирующего вызова (тупик в вызываемом процессе?). Возможно, я смогу создать тестовое приложение, чтобы воспроизвести это конкретное предварительное условие, но это займет время.
Я нашел несколько похожих трассировок и отчетов об ошибках в Интернете, указывающих на то, что проблема не связана с устройством или поставщиком (хотя, возможно, зависит от версии платформы).
Точный сервис, с которым взаимодействуют, также не имеет значения.
PS 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 --