Android фатальный сигнал 11 (SIGSEGV) на 0x636f7d89 (код=1). Как его можно выследить?
Я читал другие сообщения о отслеживании причин получения SIGSEGV в приложения Android. Я планирую очистить свое приложение для возможных NullPointers, связанных с использованием холста, но мой SIGSEGV barfs вверх по другому адресу памяти каждый раз. Плюс я видел code=1 и code=2 . Если адрес памяти был 0x00000000 , Я бы зацепка это, появляется сообщение об.
последний, который я получил, был code=2 :
любые предложения о том, как отслеживать это вниз?
когда я пишу это, я думаю, что это действительно проблема. Головная боль не раскалывается. из узла и OverlayItem из NodeOverlayItem, это то, что действие будет нуждаться в некоторых данных из узла, который содержит служба. Плюс, когда создается действие (onResume и т. д. ) объекты OverlayItem необходимо будет воссоздать из данных узла, который служба поддерживала в то время как действие отсутствовало. например, вы запускаете приложение, сервис собирает данные, пользовательский интерфейс отображает его, вы идете домой, потом обратно в приложение, упражнение нужно вытащить и заново создать OverlayItem по из последних данных узла службы.
Я знаю, что это не большие или четкие вопросы. Это похоже на то, что все мои вопросы so являются нишевыми или неясными. Если у кого-то есть предложение о том, как интерпретировать эти SIGSEGV ошибки, было бы весьма признателен!
обновление Вот последний сбой, зафиксированный во время сеанса отладки. У меня есть 3 из этих устройств, используемых для тестирования, и они не все сбой надежно, когда я разрабатываю и тестирую. Я включил немного больше просто таким образом, можно отметить ведение журнала GC. Вы можете видеть, что проблема, вероятно, не связана с исчерпанием памяти.
13 ответов
во-первых, получите трассировку стека надгробия, она будет печататься каждый раз, когда ваше приложение падает. Что-то вроде этого:—20—>
затем используйте addr2line утилита (найти его в цепочке инструментов NDK), чтобы найти функцию, которая падает. В этом примере, Вы делаете
и вы увидите, где у вас проблема. Конечно, это не поможет вам так, как в libc.
таким образом, вы можете объединить утилиты arm-eabi-objdump чтобы найти финал цель.
поверьте мне, это трудная задача.
просто для обновления. Я думаю, что я делал Android native build из целого дерева источников довольно долго, до сегодняшнего дня я сам внимательно читал документы NDK. С момента выпуска NDK-r6 он предоставил утилиту под названием ndk-stack .
Ниже приводится содержание из официальных документов NDK с NDK-r9 tar мяч.
описание:
ndk-stack — это простой инструмент, который позволяет фильтровать трассировки стека по мере их появления на выходе «ADB logcat» и заменять любой адрес внутри общей библиотеки соответствующими : значениями.
в двух словах, это будет означать что-то вроде:
в более читаемый вывод:
использование:
для этого вам сначала понадобится каталог, содержащий символические версии общих библиотек приложения. Если вы используете систему сборки NDK (т. е. ndk-build ), то они всегда находятся под $PROJECT_PATH / obj / local/, где стоит ABI вашего устройства (т. е. armeabi по умолчанию).
вы можете кормить logcat текст либо как прямой вход в программу, например:
или вы можете использовать опцию-dump, чтобы указать logcat в качестве входного файла, например:
инструмент ищет начальную строку, содержащую начало в logcat вывод, т. е. что-то, что выглядит так:
при копировании / вставке трассировок не забывайте эту строку из трассировок или ndk-stack не будет работать правильно.
следующей версии ndk-stack попытается запустить adb logcat и выберите путь к библиотеке автоматически. На данный момент вам придется сделать эти шаги вручную.
сейчас ndk-stack не обрабатывает библиотеки, в которых нет отладочной информации. Может быть полезно попытаться обнаружить ближайшую точку входа функции к заданному адресу ПК (например, как в libc.так пример выше).
ОК! Мне очень жаль тех, кто действительно представил комментарии и ответы, но я нашел проблему. Я не думаю, что это поможет многим другим, пытающимся отследить их личный SIGSEGV, но мой (и это было очень сложно) был полностью связан с этим:
libcrypto.так что в моей помойке меня вроде как просветили. Я делаю MD5 хэш пакетных данных при попытке определить, если я уже я видел пакет и пропустил бы его, если бы видел. Я думал, что в какой-то момент это была уродливая проблема с потоками, связанная с отслеживанием этих хэшей, но оказалось, что это java.безопасность.MessageDigest класс! Это небезопасно!
Я поменял его с UID, который я заполнял в каждом пакете на основе UUID устройства и метки времени. С тех пор никаких проблем.
Я думаю, что урок, который я могу передать тем, кто был в моей ситуации, даже если вы 100% Java-приложение, обратите внимание в родную библиотеку и символ, отмеченный в аварийном дампе для подсказок. Поиск в гугле для SIGSEGV + lib .таким образом, имя будет идти намного дальше, чем бесполезный код=1 и т. д. Затем подумайте о том, где ваше Java-приложение может коснуться собственного кода, даже если вы ничего не делаете. Я допустил ошибку, предположив, что это проблема с потоком Service + UI, где холст рисовал что-то, что было null (самый распространенный случай, когда я гуглил на SIGSEGV), и проигнорировал возможность, что это могло быть полностью связано с код, который я написал, был связан с lib .значит, на аварийной свалке. Естественно, java.безопасность будет использовать собственный компонент в libcrypto.поэтому для скорости, поэтому, как только я понял, я погуглил для Android + SIGSEGV + libcrypto.так и нашли документированную проблему. Удачи!
Я получал эту ошибку, сохраняя объект в общих настройках в виде преобразованной строки gson. Строка gson не была хорошей, поэтому извлечение и десериализация объекта на самом деле работали неправильно. Это означало, что любые последующие обращения к объекту привели к этой ошибке. Страшно 🙂
Я также получил эту ошибку много раз и я ее решила. Эта ошибка будет возникать в случае управления памятью в родной стороне.
приложения является доступ к памяти за пределами своего адресного пространства. Скорее всего это недопустимый указатель. SIGSEGV = ошибка сегментации в собственном коде. Поскольку это не происходит в Java-коде вы не увидите трассировку стека с деталями. Однако вы все равно можете увидеть некоторую информацию трассировки стека в logcat, если немного осмотритесь после сбой процесса приложения. Он не сообщит вам номер строки в файле, но сообщит вам, какие объектные файлы и адреса использовались в цепочке вызовов. Оттуда вы часто можете выяснить, какая область кода является проблематичной. Вы также можете настроить собственное соединение gdb с целевым процессом и поймать его в отладчике.
я столкнулся с этой ошибкой, когда пытался получить доступ к «холсту» за пределами onDraw()
очень плохая практика :/
попробуйте отключить аппаратное ускорение в Android в манифесте.
Я получал эту ошибку при использовании растрового изображения:
что исправило проблему для меня, так это уменьшить размер растрового изображения (>1000px до 700px).
я столкнулся с SIGSEGV на Android 4.4.4 (Nexuses, Samsungs) И оказалось, что фатальная ошибка была в разборе null String используя DecimalFormat
на Android > 21 он был успешно обработан с помощью try / catch
сегодня я столкнулся с Fatal signal 11 (SIGSEGV), code 1, fault addr 0x8 in tid 18161 проблема, и я борюсь полдня, чтобы решить эту проблему.
Я пробовал много вещей, очищая кэш и удаляя .файл gradle и все такое.
Наконец-То Я disable Instant Run и теперь я не получаю эту проблему снова. Теперь мое приложение работает после включения instant run. Это может быть проблема мгновенного запуска, попробуйте отключить и включить instant run
Если вы используете библиотеку vitamio и эта фатальная ошибка возникает.
затем убедитесь, что в вашем проекте gradle targetSdkVersion должно быть меньше 23.
проверьте свой код JNI / native. Одна из моих ссылок была нулевой, но она была прерывистой, поэтому это было не очень очевидно.
Проверьте свои собственные функции, правильно ли он возвращается или нет,если он не возвращается, добавьте инструкции return.
в моем случае проблема была вызвана профилировщиком Android. В Android Studio нажмите «профилировщик Android «и»завершить сеанс».
по иронии судьбы, это также вызывало экстремальные проблемы с производительностью в приложении.
Источник
Приложение сбой (иногда) с фатальным сигналом 11 (SIGSEGV), код 1
Я разрабатываю приложение со ЗДЕСЬ sdk, и все работает до сих пор. Я получаю такие ошибки:
Fatal signal 11 (SIGSEGV), code 1, fault addr 0x750057 in tid 10206 (FinalizerDaemon)
Или этот:
Fatal signal 11 (SIGSEGV), code 1, fault addr 0x94789680 in tid 24605 (FinalizerDaemon)
И они делают мое приложение крахом.
Это не всегда одни и те же ошибки, но они всегда приходят в одиночку в моем Logcat, без какой-либо другой информации.
Во всем моем приложении я использую объекты и службы ЗДЕСЬ, и даже при печати stacktrace я не получаю больше информации об ошибках.
Я просто заметил, что эти ошибки появляются довольно случайным образом, но только тогда, когда я использую эти объекты / службы.
Я использую реальное устройство для тестирования моего приложения, компакт-диска Sony Xperia Z3, поэтому я не думаю, что это происходит отсюда.
Я действительно потерян, поэтому, если кто-то даже знает, как получить больше информации об ошибках, пожалуйста, помогите
РЕДАКТИРОВАТЬ :
EDIT 2: теперь я уверен, что авария происходит, когда я извлекаю объекты HERE из базы данных с помощью gson.
Следующий код работает, когда все выполняется в одной и той же среде выполнения приложения, но когда я сохраняю строку в базе данных, закройте приложение, а затем снова откроем его, я получаю Fatal signal при преобразовании json string обратно в объект.
Я действительно не знаю, почему это не работает.
1) Сначала определите, является ли это ошибкой в андроиде, сторонних библиотеках или вашем устройстве, чтобы вы могли узнать, к какому пути.
Этот ответ дает решение, как это сделать:
Если вы написали (или используете) плагин, который, в свою очередь, использует собственный код C / C ++ через NDK, это может указывать на ошибку в этом нативном коде.
В противном случае это ошибка в прошивке устройства или эмулятора, который вы тестируете.
Если вы можете воспроизвести это в эмуляторе, на устройстве Nexus с оригинальным ПЗУ или на разных устройствах от разных производителей, это, вероятно, ошибка в самом Android. В этом случае создайте образец проекта, который может воспроизвести ошибку, и отправьте его вместе со всей трассировкой стека на http://b.android.com , отслеживатель проблем ОС Android.
Если вы сталкиваетесь с этим только на одном устройстве или на одном стороннем ПЗУ, это, вероятно, более конкретная ошибка – лучше всего связаться с производителем устройства или издателем ПЗУ с вашими симптомами.
Вот эти два вопроса, которые обсуждают полученную вами ошибку:
Android Fatal signal 11 (SIGSEGV) на 0x636f7d89 (код = 1). Как его можно отследить?
Фатальный сигнал 11 (SIGSEGV) при 0x00000000 (код = 1) – PhoneGap
2) Что касается анализа ваших значений geobounds (как бы там ни было, может быть, проблема), убедитесь, что вы правильно обрабатываете ваш синтаксический анализ между Gson и Json с правильными значениями geobound. Похоже, что вы храните значения не в соответствии с тем, как вы их возвращаете.
ToJson () – преобразовать объект Java в JSON
FromJson () – преобразовать объект JSON в Java
Из этого ответа :
Эти вопросы SO дают более подробную информацию:
Как разбирать json-парсинг Использование GSON в андроиде
Разбор JSON с gson и GsonBuilder ()
3) Убедитесь, что вы передаете правильные значения для ваших геобондовых координат. Этот вопрос Значение не входит в ожидаемый диапазон GeoboundingBox WinRT (хотя это C # дает хороший пример того, как разбить компоненты информации, которую вы пытаетесь сохранить и получить.
И научитесь разбирать свой json с gson:
Используйте Gson для работы с JSON в приложениях для Android
Существует также это gihub repo для вас, чтобы просмотреть больше идей.
Вы можете вставить больше информации из adb logcat? В настоящее время нам недостаточно информации, чтобы помочь вам. Segfault в демозаторе финализатора может подразумевать двойное удаление собственных объектов. Без дополнительной информации это может быть где угодно в ОС или в SDK.
Пропущенные кадры означают, что ваше приложение обрабатывает множество данных в основном потоке. Пропуск 161 кадра означает более 3-х рабочих часов! Попробуйте использовать AsyncTasks или потоки для оптимизации вашего приложения.
Кажется, вы используете десериализатор типа GSON, который не будет правильно строить наши собственные объекты. В ручном режиме десериализация лата, lng и вызов нового GeoBoundingBox () не будет разбиваться.
Я решил такую же проблему, следуя коду.
Добавьте android:vmSafeMode=»true» в теге приложения в файле манифеста .
Источник
Android Fatal signal 11 (SIGSEGV) на 0x636f7d89 (код = 1). Как его можно отследить?
Я читал другие сообщения о отслеживании причин получения SIGSEGV в приложении для Android. Я планирую вычеркнуть свое приложение для возможных NullPointers, связанных с использованием Canvas, но мой SIGSEGV каждый раз заполняет другой адрес памяти. Плюс я видел code=1 и code=2 . Если бы адрес памяти был 0x00000000 , я бы понял, что это NullPointer.
Последний, который я получил, был code=2 :
Любые предложения о том, как отслеживать это?
У меня есть подозреваемый, но я пока не экспериментирую с ним. Мое приложение использует API OSMDroid для офлайн-сопоставления. Класс OverlayItem представляет маркеры / узлы на карте. У меня есть Служба, которая собирает данные через сеть, чтобы заполнить OverlayItem, которые затем отображаются на карте. Чтобы упростить мой дизайн, я расширил OverlayItem в свой собственный класс NodeOverlayItem, который включает некоторые дополнительные атрибуты, которые я использую в деятельности пользовательского интерфейса и в Сервисе. Это дало мне один пункт информации о деталях для пользовательского интерфейса и службы. Я использовал Intents для трансляции в Activity, чтобы обновить карту пользовательского интерфейса, когда что-то изменилось. Операция привязывается к Сервису, и для получения списка NodeOverlayItem существует метод службы. Я думаю, что это может быть использование OSMDroid API OverlayItem и моей информации об обновлении узла одновременно. (Проблема параллелизма)
Когда я пишу это, я думаю, что это действительно проблема. Головная боль не расщепляет узел и элемент OverlayItem из NodeOverlayItem, это значит, что для операции потребуется некоторые данные из узла, который выполняется Сервисом. Плюс, когда создается действие (onResume и т. Д.), Объекты OverlayItem необходимо будет восстановить из данных узла, которые Служба поддерживала, пока активность не была удалена. Например, вы запускаете приложение, Служба собирает данные, пользовательский интерфейс отображает его, вы переходите в «Домой», а затем обратно в приложение, «Активность» должна будет вытягивать и воссоздавать OverlayItem из последних данных узла службы.
Я знаю, что это не большие или четкие вопросы. Это похоже на то, что все мои вопросы SO нише или неясны. Если у кого-то есть предложение о том, как интерпретировать ошибки SIGSEGV , было бы весьма полезно!
ОБНОВЛЕНИЕ Вот последний сбой, зафиксированный во время сеанса отладки. У меня есть 3 из этих устройств, которые используются для тестирования, и они не все работают с уверенностью, когда я разрабатываю и тестирую. Я включил немного больше, чтобы можно было зарегистрировать GC. Вы можете видеть, что проблема, вероятно, не связана с исчерпанием памяти.
Во-первых, получите трассировку стека надгробий, он будет печататься каждый раз, когда ваше приложение выйдет из строя. Что-то вроде этого:
Затем используйте утилиту addr2line (найдите ее в цепочке инструментов NDK), чтобы найти addr2line функцию. В этом примере вы делаете
И вы увидите, где у вас проблема. Конечно, это не поможет вам, так как это в libc.
Таким образом, вы можете объединить утилиты arm-eabi-objdump чтобы найти конечную цель.
Поверьте, это сложная задача.
Просто для обновления. Я думаю, что довольно долго я делал сборку Android на основе дерева исходных текстов, и до сегодняшнего дня я тщательно читал документы NDK. С момента выпуска NDK-r6 он предоставил утилиту ndk-stack .
Ниже приведен контент официальных документов NDK с шаром NDK-r9.
Обзор:
ndk-stack – простой инструмент, который позволяет фильтровать трассировки стека, как они появляются на выходе «adb logcat», и заменять любой адрес внутри общей библиотеки соответствующими значениями.
В двух словах, это переведет что-то вроде:
В более читаемый вывод:
Применение:
Для этого вам сначала понадобится каталог, содержащий символические версии разделяемых библиотек вашего приложения. Если вы используете систему сборки NDK (т. ndk-build ), то они всегда находятся под $ PROJECT_PATH / obj / local /, где обозначается ABI вашего устройства (то есть armeabi по умолчанию).
Вы можете logcat текст как прямой вход в программу, например:
Или вы можете использовать параметр -dump для указания logcat в качестве входного файла, например:
Инструмент ищет начальную строку, содержащую logcat выводе logcat , то есть что-то похожее:
При копировании / вставке следов не забывайте эту строку из трасс, иначе ndk-stack не будет работать правильно.
Будущая версия ndk-stack попытается запустить adb logcat и автоматически выбрать путь к библиотеке. На данный момент вам придется сделать эти шаги вручную.
На данный момент ndk-stack не обрабатывает библиотеки, в которых нет отладочной информации. Может оказаться полезным попытаться обнаружить ближайшую точку входа функции на заданный адрес ПК (например, как в примере libc.so выше).
ОК! Мне очень жаль тех, кто действительно подавал комментарии и ответы, но я нашел проблему. Я не думаю, что это поможет многим другим, кто пытается отследить их личный SIGSEGV, но мой (и это было очень сложно) полностью связано с этим:
Libcrypto.so в моем дампе вроде меня. Я делаю хеш MD5 пакетных данных, пытаясь определить, видел ли я этот пакет, и пропустил его, если бы у меня было. Я подумал, что в какой-то момент это была уродливая проблема с потоками, связанная с отслеживанием этих хэшей, но оказалось, что это класс java.security.MessageDigest! Это не потокобезопасно!
Я поменял его с помощью UID, который я набивал в каждом пакете на основе UUID устройства и отметки времени. С тех пор проблем нет.
Я предполагаю, что урок, который я могу передать тем, которые были в моей ситуации, даже если вы – 100% -ное приложение Java, обратите внимание на собственную библиотеку и символ, отмеченные в дампе сбоя для подсказок. Googling для SIGSEGV + имя lib .so будет намного дальше, чем бесполезный код = 1 и т. Д. Затем подумайте о том, где ваше приложение Java может касаться собственного кода, даже если это ничего не делает. Я допустил ошибку, предположив, что это проблема с реализацией Service + UI, где Canvas рисует что-то, что было null (наиболее распространенный случай, когда я googled на SIGSEGV) и игнорировал возможность, что он мог быть полностью связан с кодом, который я написал, который был Связанных с lib .so в дампе сбоя. Естественно, java.security будет использовать собственный компонент в libcrypto.so для скорости, поэтому, как только я узнал, я Googled для Android + SIGSEGV + libcrypto.so и нашел документированную проблему. Удачи!
Я также получил эту ошибку много раз, и я решил ее. Эта ошибка будет возникать в случае управления памятью на родной стороне.
Ваше приложение обращается к памяти за пределами своего адресного пространства. Скорее всего, это недопустимый доступ указателя. SIGSEGV = ошибка сегментации в собственном коде. Так как это не происходит в коде Java, вы не увидите трассировку стека с подробностями. Тем не менее, вы можете по-прежнему видеть некоторую информацию о трассировке стека в logcat, если вы немного оглядитесь после сбоя процесса приложения. Он не укажет номер строки в файле, но расскажет вам, какие файлы объектов и адреса были использованы в цепочке вызовов. Оттуда вы часто можете выяснить, какая область кода проблематична. Вы также можете настроить собственное подключение gdb к целевому процессу и поймать его в отладчике.
Я получал эту ошибку, сохраняя объект в общих предпочтениях как преобразованная строка gson. Строка gson не была хорошей, поэтому извлечение и десериализация объекта на самом деле не работали правильно. Это означало, что любой последующий доступ к объекту приводил к этой ошибке. Страшно 🙂
Я получал эту ошибку при использовании растрового изображения:
Для меня проблема заключалась в уменьшении размера растрового изображения (> 1000px до 700px).
Я столкнулся с SIGSEGV на Android 4.4.4 (Nexuses, Samsung). И оказалось, что фатальная ошибка заключалась в анализе null String с использованием DecimalFormat
На Android> 21 было успешно обработано с помощью try / catch
Я столкнулся с этой ошибкой, когда попытался получить доступ к «холсту» за пределами onDraw()
Очень плохая практика: /
Проверьте свой JNI / собственный код. Одна из моих ссылок была нулевой, но она была прерывистой, поэтому это было не очень очевидно.
Источник
