Странный сбой моего приложения для Android - PullRequest
1 голос
/ 04 июня 2011

Я написал приложение для Android полностью на C, используя новый код native_app_glue, который поставляется с последней версией Android NDK. Все работает нормально, кроме одной странной вещи. Когда я закрываю свое приложение и запускаю его снова, у меня возникает сбой в моем общем объекте .so. Я использовал addr2line, чтобы найти функцию, которая аварийно завершает работу, но это не имеет никакого смысла, потому что это всегда другая функция, вызывающая сбой, и, конечно, в первый раз, когда она тоже работала нормально. Так что должно быть что-то еще.

У кого-нибудь есть идея, что может вызвать такое поведение? Как я уже сказал, поведение выглядит так:

1) Первый запуск -> приложение всегда работает нормально 2) Второй раз запуска -> приложение вылетает 3) Запуск в третий раз -> приложение снова работает нормально 4) Запуск в четвертый раз -> приложение снова вылетает 5) Пятое время запуска -> снова работает нормально 6) Шестой раз -> крушение и так далее и тому подобное.

Я не знаю, что там не так. Может быть, мое приложение не закрывается правильно? Но я получаю и обрабатываю оба термина сообщений (APP_CMD_TERM_WINDOW и APP_CMD_DESTROY). Я действительно понятия не имею, что там не так ...

Спасибо за помощь!

Редактировать: вот журнал сбоя:

I/DEBUG   (   31): *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** 
I/DEBUG   (   31): Build fingerprint: 'generic/sdk/generic:2.3.1/GSI11/93351:eng/test-keys'
I/DEBUG   (   31): pid: 1105, tid: 1114  >>> com.example.testapp <<<
I/DEBUG   (   31): signal 11 (SIGSEGV), code 1 (SEGV_MAPERR), fault addr 00000058
I/DEBUG   (   31):  r0 8382746d  r1 00000000  r2 00000058  r3 00000058
I/DEBUG   (   31):  r4 00000000  r5 8382746d  r6 00242920  r7 00000554
I/DEBUG   (   31):  r8 00245150  r9 001ec8e0  10 839651dc  fp 00000000
I/DEBUG   (   31):  ip 839654e0  sp 435fc2b0  lr 8381c78f  pc 83861858  cpsr 00000030
I/DEBUG   (   31):          #00  pc 00061858  /data/data/com.example.testapp/lib/libtestapp.so
I/DEBUG   (   31):          #01  pc 0001c78a  /data/data/com.example.testapp/lib/libtestapp.so
I/DEBUG   (   31):          #02  pc 0001d7d4  /data/data/com.example.testapp/lib/libtestapp.so
I/DEBUG   (   31):          #03  pc 000ab1fa  /data/data/com.example.testapp/lib/libtestapp.so
I/DEBUG   (   31):          #04  pc 000fc9e2  /data/data/com.example.testapp/lib/libtestapp.so
I/DEBUG   (   31):          #05  pc 00011a7c  /system/lib/libc.so
I/DEBUG   (   31):          #06  pc 00011640  /system/lib/libc.so

Ответы [ 2 ]

1 голос
/ 28 июня 2012

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

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

0 голосов
/ 30 октября 2012

Из вашего дампа кажется, что проблема не в каком-либо вызове native_app_glue, а в вашем исходном коде.

Изначально, если происходит сбой при вызове сторонней функции, скорее всего, у вас будет хотя бы одна ссылка на libc.so в вашей обратной трассировке, но вместо этого первая ссылка будет на вашу собственную библиотеку. Не могли бы вы опубликовать информацию о стеке? не увидев исходный код, я бы поставил на какую-то ссылку на указатель NULL.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...