Я пытаюсь изначально буферизовать аудио, полученное из OpenSL ES API.
Чтобы сделать это, я реализовал простую очередь в своем C-файле, который содержит буферизованные данные.
Затем я использую собственный pthread для передачи буферизованных данных на уровень Java, если буферизованных данных достаточно (минимум 3 буферизованных аудиокадра, 1 кадр = 30 мс аудио).
Однако, пока собственный поток ожидает данные от API OpenSL ES, я получаю сообщение об ошибке SIGSEGV с собственной трассировкой стека. Однако я не вижу, где произошла ошибка, так как трассировка стека невероятно бесполезна .... Это потому, что счетчик программы не отображается, только регистры.
08-30 14:09:51.148: INFO/DEBUG(21802): *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** ***
08-30 14:09:51.148: INFO/DEBUG(21802): Build fingerprint: 'samsung/GT-I9000/GT-I9000:2.3.2/GINGERBREAD/XWJV1:user/release-keys'
08-30 14:09:51.148: INFO/DEBUG(21802): pid: 21803, tid: 21811 >>> w�� <<<
08-30 14:09:51.148: INFO/DEBUG(21802): signal 11 (SIGSEGV), code 1 (SEGV_MAPERR), fault addr fffc0000
08-30 14:09:51.148: INFO/DEBUG(21802): r0 405329c0 r1 fffc0000 r2 000001a0 r3 00000000
08-30 14:09:51.148: INFO/DEBUG(21802): r4 405329c0 r5 00000000 r6 002b5688 r7 000001e0
08-30 14:09:51.148: INFO/DEBUG(21802): r8 84b00dc5 r9 00000000 10 00100000 fp 00000001
08-30 14:09:51.148: INFO/DEBUG(21802): ip 822a5684 sp 46e6dea0 lr 8224b657 pc 8010dde8 cpsr 20000010
08-30 14:09:51.148: INFO/DEBUG(21802): d0 697320657565757a d1 6974696c69747565
08-30 14:09:51.148: INFO/DEBUG(21802): d2 6f696475412f733a d3 6f737365636f7220
08-30 14:09:51.148: INFO/DEBUG(21802): d4 006c006c00690068 d5 006100650074002e
08-30 14:09:51.148: INFO/DEBUG(21802): d6 006e0069006c006d d7 00730075002e006b
08-30 14:09:51.148: INFO/DEBUG(21802): d8 0000000000000000 d9 0000000000000000
08-30 14:09:51.148: INFO/DEBUG(21802): d10 0000000000000000 d11 0000000000000000
08-30 14:09:51.148: INFO/DEBUG(21802): d12 0000000000000000 d13 0000000000000000
08-30 14:09:51.148: INFO/DEBUG(21802): d14 0000000000000000 d15 0000000000000000
08-30 14:09:51.148: INFO/DEBUG(21802): d16 000000004052e0f8 d17 0000000000000000
08-30 14:09:51.148: INFO/DEBUG(21802): d18 0000000000000000 d19 0000000000000000
08-30 14:09:51.148: INFO/DEBUG(21802): d20 3fe0000000000000 d21 8000000000000000
08-30 14:09:51.148: INFO/DEBUG(21802): d22 0000000000000000 d23 0000000000000000
08-30 14:09:51.148: INFO/DEBUG(21802): d24 0000000000000000 d25 3ff0000000000000
08-30 14:09:51.148: INFO/DEBUG(21802): d26 0000000000000000 d27 3ff0000000000000
08-30 14:09:51.148: INFO/DEBUG(21802): d28 0000000000000000 d29 4000000000000000
08-30 14:09:51.148: INFO/DEBUG(21802): d30 0000000000000000 d31 3fe0000000000000
08-30 14:09:51.148: INFO/DEBUG(21802): scr 60000012
Это вся трассировка стека ... Если кто-нибудь может указать мне, где я мог бы начать с отладки этой ошибки? Мне известна утилита addr2line, предоставляемая NDK, но без счетчика программ я не могу определить, где произошла ошибка ...
Обновление
В соответствии с данными предложениями * http://groups.google.com/group/android-ndk/browse_thread/thread/d7fe50f356f50896#, Я смог дополнительно исследовать проблему. После использования инструмента Addr2Line в libOpenSLES.so и libc.so я получил успех с libc.so. Тем не менее, этот файл автоматически генерируется Python и записывается на ассемблере. Это, однако, системный вызов. Файл, о котором я говорю, это fchownat.S:
/* autogenerated by gensyscalls.py */
#include <sys/linux-syscalls.h>
.text
.type fchownat, #function
.globl fchownat
.align 4
.fnstart
fchownat:
mov ip, sp
.save {r4, r5, r6, r7}
stmfd sp!, {r4, r5, r6, r7}
ldmfd ip, {r4, r5, r6}
ldr r7, =__NR_fchownat
swi #0
ldmfd sp!, {r4, r5, r6, r7}
movs r0, r0
bxpl lr
b __set_syscall_errno
.fnend
Кто-нибудь получил представление о том, почему это может произойти сбой здесь? А еще лучше, кто-нибудь может объяснить, что он на самом деле делает? Из того, что я обнаружил, это системный вызов для смены владельца файла ... Но я не могу понять это из кода ... Мои навыки сборки не слишком ужасны ...