Может ли недостаток памяти вызвать ошибки сегмента в нативном коде?

У меня есть группа сбоев в нативном коде, которые встречаются редко, но происходят последовательно с SEGV_MAPERR или SEGV_ACCERR. Crashlytics почти всегда сообщает об этих сбоях с очень низким объемом ОЗУ (обычно 1-5%). «Нормальные» сбои (то есть те, которые я отлаживал) не имеют паттерна в свободной памяти.

Возможно ли, что эти сбои вызваны нехваткой памяти? Каков будет механизм для этого? Есть ли какой-нибудь способ определить, являются ли это сбоями из-за недостатка памяти или ошибками программирования (неправильное использование указателей и т. Д.)? Во многих случаях сбой происходит в библиотеке, которую я не могу отладить, и я не могу воспроизвести сбои на моих устройствах.

Вот некоторые из этих сбоев, извлеченных из консоли разработчика, потому что она предоставляет немного больше деталей, чем Crashlytics в трассировке в этих случаях:

********** Crash dump: **********
Build fingerprint: 'htc/a32eul_metropcs_us/htc_a32eul:5.1/LMY47O/637541.3:user/release-keys'
pid: 10902, tid: 10989, name: .xxx.xxxx  >>> com.xxx.xxxxx <<<
signal 11 (SIGSEGV), code 2 (SEGV_ACCERR), fault addr 0x97f78000
Stack frame #00 pc 0004cd80  /data/app/xxx.xxx.xxxxx-1/lib/arm/libxxx.so: Routine xxxxxMixerInterleavedFloatOutput at libgcc2.c:?

********** Crash dump: **********
Build fingerprint: 'Xiaomi/land/land:6.0.1/MMB29M/V8.1.1.0.MALMIDI:user/release-keys'
pid: 2661, tid: 2746, name: .xxx.xxxx  >>> com.xxx.xxxx <<<
signal 11 (SIGSEGV), code 1 (SEGV_MAPERR), fault addr 0x0
Stack frame #00 pc 00016954  /system/lib/libc.so (__memcpy_base+36)
Stack frame #01 pc 0000b14c  /data/app/com.xxx.xxxx-2/lib/arm/libswresample-2.so: Routine ??
??:0

5

Решение

Есть две основные возможности:

  1. Низкое состояние памяти само по себе не приведет к возникновению ошибки в работающем приложении. Может случиться так, что, когда приложение запрашивает выделение ему дополнительной памяти, запрос на выделение памяти не выполняется. Это хорошо определенное состояние памяти. Документально подтверждено, что соответствующие системные вызовы могут не работать при выделении памяти. Но часто случается так, что приложение не кодируется должным образом для проверки неудачного запроса на выделение памяти, и по этой причине происходит сбой. В этом случае, это не правда, что из-за недостаточной памяти приложения происходит ошибка в приложении, это ошибка приложения.

  2. Ядро Linux перекрывает доступную память. В результате этого возможно, что у ядра не будет выбора, кроме как выбрать процесс, который нужно уничтожить, когда будет исчерпана вся доступная RAM.

Тем не менее, в случае включения убийцы ООМ, выбранные жертвы уничтожаются SIGKILL, SEGFAULT указывает на ошибку приложения.

6

Другие решения

Других решений пока нет …

По вопросам рекламы ammmcru@yandex.ru
Adblock
detector