Странный сбой моего приложения для Android

Question

Странный сбой моего приложения для Android

1

Я написал приложение для 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

andy 04 июнь 2011, в 18:16

Источник

0

Вы можете опубликовать фрагмент кода с logcat
Sumant 04 июнь 2011, в 15:53
0

@Sumant: здесь вы идете
andy 04 июнь 2011, в 16:40
0

Скорее всего, вы используете что-то, что должно быть нестатичным статическим способом (то есть зависать на нем в контексте процесса), и когда вы используете его ненадлежащим образом, во время перезапуска, который повторно использует существующий процесс, вы терпите крах, пытаясь получить доступ к чему-то, что больше не действует.
Chris Stratton 27 июнь 2012, в 20:19

Показать ещё 1 комментарий

Теги:

android

android-ndk

2 ответа

Ещё вопросы

Вы можете опубликовать фрагмент кода с logcat
Скорее всего, вы используете что-то, что должно быть нестатичным статическим способом (то есть зависать на нем в контексте процесса), и когда вы используете его ненадлежащим образом, во время перезапуска, который повторно использует существующий процесс, вы терпите крах, пытаясь получить доступ к чему-то, что больше не действует.

Alvin Fong · Answer 1 · 2012-06-27T17-58-00.000Z

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

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

Вы думаете об обычном java-invoking-jni, но этот вопрос касается нативной деятельности без написанных разработчиком java-компонентов. Кроме того, загрузка уже загруженной библиотеки не должна вызывать сбой.

jcm · Answer 2 · 2012-10-30T13-40-00.000Z

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

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