Подтвердить что ты не робот

Xcode покидает процессы зомби после запуска iOS-тестов/симуляторов

После работы в Xcode в приложении iOS в течение нескольких дней я заметил, что вокруг висит более 100 процессов зомби. Кажется, что каждый раз, когда я запускал модульные тесты, каждый раз, когда я запускал полное приложение в симуляторе, каждый раз я запускал модульные тесты. Здесь образец (очищенный и усеченный):

> ps -efj | grep $PRODUCT_NAME
  502  2794   236   0 Wed12AM ??         0:00.00 (MyProduct)  me            2794      0    1 Z      ?? 
  502  2843   236   0 Wed01AM ??         0:00.00 (MyProduct)  me            2843      0    1 Z      ?? 
  502  2886   236   0 Wed01AM ??         0:00.00 (MyProduct)  me            2886      0    1 Z      ?? 
...
  502 13711   236   0 Thu11PM ??         0:00.00 (MyProduct)  me           13711      0    1 Z      ?? 
  502 13770   236   0 Thu11PM ??         0:00.00 (MyProduct)  me           13770      0    1 Z      ?? 
  502 14219   236   0 10:35AM ??         0:00.00 (MyProduct)  me           14219      0    1 Z      ?? 
  502 14280   236   0 10:38AM ??         0:00.00 (MyProduct)  me           14280      0    1 Z      ?? 

Z во втором столбце указывает на то, что они являются зомби-процессами. 236 в третьем столбце является родительским PID, который принадлежит моему пользователю launchd в этом случае.

Обратите внимание, что некоторые из процессов имеют несколько дней. Я запустил и повторно открыл Xcode несколько раз в течение этого периода времени.

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

4b9b3361

Ответ 1

Они не особенно занимают много места.

Это, кажется, артефакт устройства Xcode, ненадлежащим образом убивающий подпроцессы.

У меня та же проблема, но я отмечаю, что зомби принадлежат, в моем случае, ppid 271, который является вызовом launchd под моим именем, а не всей системой.

Мне любопытно, что может произойти, если я убью или сделаю этот процесс.

В любом случае выход из системы, вероятно, очистит зомби. И, конечно, перезагрузка будет, но этого следует избегать в моей книге.


О, это было довольно плохо. Не убивайте свой запуск, он бесцеремонно убивает ваш сеанс, но не дает вам возможности вернуть его, например, дать вам экран входа.

Мне придется посмотреть и посмотреть, что я оставил зомби из-за остановки Xcode. Кажется, здесь может быть пара немых вещей. Это ваш процесс не ждет ребенка, он становится зомбированным. Если родитель умирает, то, по-видимому, следующая вещь попадает в строку, которая в этом случае запускается. Launchd должен ждать() для этого, но, может быть, это путает?

Ответ 2

После некоторых особенно тяжелых сессий Xcode, где мой MBP звучал так, как будто его просили выполнить STARNET Init Procedure, я решил потратить несколько минут на изучение этого бессмысленного процесса зомби... в конце концов, ящик Unix, t fork - бесполезная коробка Unix. У меня могут быть хорошие новости. Надеюсь, посмотрим. Запуск Xcode 4.6 на 10.8.2 здесь.

Проблема с зомби появляется независимо от использования GDB или LLDB. Приложение, работающее в симуляторе, принадлежит процессу отладки - либо GDB, либо "debugserver" в случае LLDB. Когда вы нажимаете "Остановить", процесс приложения, запущенный в симуляторе, переходит в зомби. Это звучит как нечистая последовательность выключения.

В ожидании, а не ударе "Остановить", я приостановил приложение, а в консоли отладки (LLDB в моем случае) я отсоединился от работающего приложения, используя "отладку процесса". Быстрый ps проверяет, что debugserver больше не работает... пока все хорошо! Теперь приложение все еще работает в самом симуляторе, просто не под отладки. Фактически, нажатие кнопки "Стоп" теперь не работает.

В симуляторе нажмите кнопку "домой", чтобы вернуться на трамплин, затем дважды нажмите кнопку "Домой" и вручную закройте приложение. Идите в свою командную строку и ищите зомби... нет зомби! Yay.

Итак, следующий шаг - посмотреть, есть ли разумный способ выполнить эту или аналогичную процедуру выключения через python script и т.д. Курс, который не помогает, если вы находитесь в GDB. Если я могу выполнить чистое завершение работы с помощью одной команды консоли отладки, это просто вопрос привычки не ударять по сломанной кнопке Stop. Может быть, есть хакер ресурсов, чтобы полностью отключить его...:)

ИЗМЕНИТЬ № 1: пара интересных лакомых кусочков...

1.) Нажатие кнопки "Стоп" в xcode только что убивает процессы отладки и приложений - нет никакой попытки выполнить чистое закрытие. Отладка Printf в приложении делегирования приложенияWillTerminate и applicationDidEnterBackground показывает, что запущенное приложение убито с предубеждением - NSW не отображается на консоли.

2.) В отладочной консоли вызов [UIApplication terminateWithSuccess] заставит приложение прекратить "правильно", но все равно оставляет зомби... интересно, если у вас установлен контрольный набор, приложение не будет завершено:

(lldb) expression
Enter expressions, then terminate with an empty line to evaluate:
[(UIApplication *)[UIApplication sharedApplication] terminateWithSuccess]

error: Execution was interrupted, reason: breakpoint 2.1.
The process has been returned to the state before execution.
(lldb) breakpoint disable 2.1
1 breakpoints disabled.
(lldb) expression
Enter expressions, then terminate with an empty line to evaluate:
[(UIApplication *)[UIApplication sharedApplication] terminateWithSuccess]

2013-03-25 01:28:00.186 iPhone Testbed[9481:c07] -[AppDelegate applicationWillTerminate:]
(lldb) 

Таким образом, приложение проходит через какой-то процесс выключения, и завершение сеанса завершается в консоли, но у нас все еще есть зомби, поэтому он все еще не является чистым отключением.

Я думаю, что все это связано с тем, что приложение выходит на задний план в среде выполнения iOS. Когда munging обрабатывает напрямую (с помощью кнопки Stop, команды kill, отладки консоли и т.д. И т.д.). Время выполнения iOS не позволяет выполнять правильное выключение и очистку - на самом деле трамплин все еще считает, что приложение работает в фоновом режиме, даже если процесс больше не существует. Так получилось, что наши iOS и OS X runtimes являются одними и теми же - следовательно, запуск у владельца зомби.

Итак, я думаю, что решение всего этого - это определение процедуры чистого выключения на уровне iOS и, по крайней мере, возможность выполнить это через консоль отладки. Посмотрите больше на флаг UIApplicationExitsOnSuspend, посмотрите, могу ли я установить необходимые биты во время выполнения (в отличие от plist), чтобы отключить приложение при отключении отладки...