Nano Hash - криптовалюты, майнинг, программирование

Сбой на iOS, когда система очищает память и закрывает UIViewController

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

Date/Time: 2012-03-14 19:47:33.819 +0000
OS Version: iPhone OS 5.1 (9B176)
Report Version: 104
Exception Type: EXC_BAD_ACCESS (SIGSEGV)
Exception Codes: KERN_INVALID_ADDRESS at 0x30000008
Crashed Thread: 0
Thread 0 name: Dispatch queue: com.apple.main-thread
Thread 0 Crashed:
0 libobjc.A.dylib 0x30f2bf78 objc_msgSend + 16
1 MyApp 0x00003c0e -LTBaseViewController viewDidUnload (LTBaseViewController.m:145)
2 MyApp 0x00004ea2 -LTBaseTableViewController viewDidUnload (LTBaseTableViewController.m:90)
3 UIKit 0x33766bd8 -[UIViewController unloadViewForced:] + 244
4 UIKit 0x338ae492 -[UIViewController purgeMemoryForReason:] + 58
5 Foundation 0x3071a4f8 __57-NSNotificationCenter addObserver:selector:name:object:_block_invoke_0 + 12
6 CoreFoundation 0x30e95540 ___CFXNotificationPost_block_invoke_0 + 64
7 CoreFoundation 0x30e21090 _CFXNotificationPost + 1400
8 Foundation 0x3068e3e4 -NSNotificationCenter postNotificationName:object:userInfo: + 60
9 Foundation 0x3068fc14 -NSNotificationCenter postNotificationName:object: + 24
10 UIKit 0x3387926a -UIApplication _performMemoryWarning + 74
11 UIKit 0x33879364 -UIApplication _receivedMemoryNotification + 168
12 libdispatch.dylib 0x36a12252 _dispatch_source_invoke + 510
13 libdispatch.dylib 0x36a0fb1e _dispatch_queue_invoke$VARIANT$up + 42
14 libdispatch.dylib 0x36a0fe64 _dispatch_main_queue_callback_4CF$VARIANT$up + 152
15 CoreFoundation 0x30e9c2a6 __CFRunLoopRun + 1262
16 CoreFoundation 0x30e1f49e CFRunLoopRunSpecific + 294
17 CoreFoundation 0x30e1f366 CFRunLoopRunInMode + 98
18 GraphicsServices 0x33fb6432 GSEventRunModal + 130
19 UIKit 0x336f5e76 UIApplicationMain + 1074
20 MyApp 0x00004818 main (main.m:16)
21 MyApp 0x000023b4 0x1000 + 5044

Я проверил, и утечек памяти почти нет, например. при тестировании приложения в течение часа общая утечка памяти составила около 2-3 КБ, вызванная некоторыми библиотеками копирования строк. Поэтому я не верю, что это вызвано приложением. Я предполагаю, что когда телефон не перезагружается в течение некоторого времени, в фоновом режиме работают приложения, а при использовании Facebook SDK память становится проблемой, и система пытается восстановить память из случайных приложений, включая мое приложение.

У меня вопрос, как я могу предотвратить этот сбой? Как мне обрабатывать unloadViewForced на контроллере представления, чтобы сделать приложение более надежным в условиях нехватки памяти? И, наконец, прав ли я в том, что этот аварийный журнал предполагает, что сбой произошел из-за того, что система пыталась освободить память, а мое приложение не обработало это должным образом?

Любая помощь очень ценится.

ios crash facebook uiviewcontroller low-memory
19.03.2012

  • Этот сбой также происходит, когда вы запускаете его в симуляторе и используете пункт меню Simulate Memory Warning? 19.03.2012
  • Не пробовал, не знал об этой функции. Постараюсь узнать. Спасибо за эту подсказку. 19.03.2012
  • Нет, это не так :( Мы не обрабатываем didReceiveMemoryWarning где-либо в приложении. Щелчок по этой опции в меню симулятора только выводит сообщение на консоль и ничего кроме этого не делает. 19.03.2012
  • Я только что вспомнил, как правильно пользоваться этой функцией. Вы должны убедиться, что активный контроллер представления не является контроллером представления, с которым у вас произошел сбой. Убедитесь, что другой контроллер представления активен, затем используйте пункт меню. Затем неактивным контроллерам представления будет предложено освободить память. 27.03.2012
  • Спасибо, а какой пункт меню вы имеете в виду? Трудно сказать, в каком именно контроллере произошел сбой, потому что LTBaseViewController — это базовый класс для всех наших контроллеров. Таким образом, журнал сбоев не сообщает, какой именно контроллер вышел из строя. Я предположил, что это был верхний, но вы правы, что это мог быть любой из нижних контроллеров в стеке. 27.03.2012
  • Ранее упомянутый пункт меню Simulate Memory Warning в симуляторе. 27.03.2012
  • А, отлично, спасибо, попробую. 28.03.2012

Ответы:


1

Скорее всего, один из объектов, на которые ссылаются и, вероятно, освобождаются методом LTBaseViewController viewDidUnload, освобождается дважды. На самом деле, поскольку обратная трассировка указывает на то, что сбой происходит в строке 145 LTBaseViewController.m, вы сможете быстро увидеть, какой объект является виновником.

19.03.2012
  • Забыл упомянуть, что памятью в приложении управляет ARC. Таким образом, нет ручного освобождения объектов. Кроме того, я не верю, что число справа от функции — это строка. Например. в моем коде нет viewDidUnload в LTBaseViewController, поэтому он вызывает родительскую реализацию. Это смещение в байтах от начала функции. Мне нужно было бы скомпилировать на ассемблере инструкции с чередованием кода, чтобы выяснить, в какой строке возникла проблема, но я не уверен, как это сделать на MAC. 19.03.2012
  • Что находится в строке 145 файла LTBaseViewController.m? (Не LTBaseTableViewController.m). 19.03.2012
  • Заключительное предложение '}' метода viewWillAppear. 19.03.2012
  • Посмотрите на эту строку: 21 MyApp 0x000023b4 0x1000 + 5044 Это, конечно, не означает, что сбой произошел в строке 5044 исходного кода MyApp. Однако он сообщает, что это произошло по смещению 5044 байта от адреса, по которому приложение было загружено в память. 19.03.2012
  • Если вы посмотрите на конец строки трассировки стека, там написано LTBaseViewController.m:145. Это указывает на то, что проблема возникает в строке 145 «LTBaseViewController.m». (Однако, если исходный код изменился с момента создания трассировки стека, они могут быть другими.) 20.03.2012
  • ThomasW еще раз, значение 145 - это не номер строки, а смещение в байтах от начала метода в памяти!!! 21.03.2012
  • Обычное значение foo.m:123 — это ссылка на строку 123 файла foo.m, тогда как смещение представляется как + смещение. Вы можете увидеть это, создав случай сбоя теста, выполнив что-то вроде выпуска только что созданного объекта и вызова одного из его методов в iOS 4.x, а затем используя bt в отладчике. 22.03.2012
  • Ладно, тогда я мог ошибаться. Я не заметил этого, так как источники изменились после того, как произошел сбой. Мне нужно было бы синхронизироваться с этой конкретной версией, чтобы убедиться, что она не сработала в этой конкретной строке. Спасибо за помощь. 22.03.2012
  • Amiramix, ошибка в конце концов решена? Кажется, вы приняли ответ, но из разговора я не могу сказать, что послужило причиной сбоя. У меня похожая проблема: проект ARC, нет ручного выпуска, но произошел сбой, когда один контроллер представления получает предупреждение о памяти и выгружает представления. 09.08.2012
  • @BaoLei Почему бы тебе не написать о своей проблеме? 10.08.2012
    • Новые материалы
    Кластеризация: более глубокий взгляд
    Кластеризация — это метод обучения без учителя, в котором мы пытаемся найти группы в наборе данных на основе некоторых известных или неизвестных свойств, которые могут существовать. Независимо от..
    Как написать эффективное резюме
    Предложения по дизайну и макету, чтобы представить себя профессионально Вам не позвонили на собеседование после того, как вы несколько раз подали заявку на работу своей мечты? У вас может..
    Частный метод Python: улучшение инкапсуляции и безопасности
    Введение Python — универсальный и мощный язык программирования, известный своей простотой и удобством использования. Одной из ключевых особенностей, отличающих Python от других языков, является..
    Как я автоматизирую тестирование с помощью Jest
    Шутка для победы, когда дело касается автоматизации тестирования Одной очень важной частью разработки программного обеспечения является автоматизация тестирования, поскольку она создает..
    Работа с векторными символическими архитектурами, часть 4 (искусственный интеллект)
    Hyperseed: неконтролируемое обучение с векторными символическими архитектурами (arXiv) Автор: Евгений Осипов , Сачин Кахавала , Диланта Хапутантри , Тимал Кемпития , Дасвин Де Сильва ,..
    Понимание расстояния Вассерштейна: мощная метрика в машинном обучении
    В обширной области машинного обучения часто возникает необходимость сравнивать и измерять различия между распределениями вероятностей. Традиционные метрики расстояния, такие как евклидово..
    Обеспечение масштабируемости LLM: облачный анализ с помощью AWS Fargate и Copilot
    В динамичной области искусственного интеллекта все большее распространение получают модели больших языков (LLM). Они жизненно важны для различных приложений, таких как интеллектуальные..