Xcode dejando procesos zombie después de ejecutar pruebas/simulador de iOS

zombie-process

Question

Después de trabajar en Xcode en una aplicación de iOS durante unos días, me he dado cuenta de que hay más de 100 procesos de zombies dando vueltas. Parece que hay una para cada vez que ejecuté pruebas unitarias y posiblemente una para cada vez que ejecuté la aplicación completa en el simulador. Aquí hay una muestra (limpia y truncada):

> 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      ?? 

La Z en la segunda a la última columna indica que son procesos zombie. El 236 en la tercera columna es el PID principal, que pertenece a launchd mi usuario en este caso.

Tenga en cuenta que algunos de los procesos tienen varios días de antigüedad. Renuncié y volví a abrir Xcode varias veces durante este período de tiempo.

¿Alguien sabe por qué sucede esto, o si esto debería ser motivo de alarma?

Answer 1

Después de algunas sesiones de Xcode particularmente pesadas en las que mi MBP sonaba como si se le pidiera que ejecutara el Procedimiento de Inicio de STARNET, decidí dedicar unos minutos a investigar este sin sentido del proceso zombie ... después de todo, una caja de Unix que no se puede descifrar. Una caja de Unix inútil. Puede que tenga algunas buenas noticias. Con suerte, ya veremos. Ejecutando Xcode 4.6 en 10.8.2 aquí.

El problema de los zombis parece ocurrir independientemente del uso de GDB o LLDB. La aplicación que se ejecuta dentro del simulador es propiedad del proceso de depuración, ya sea GDB o "debugserver" en el caso de LLDB. Cuando presionas "Detener", el proceso de la aplicación que se ejecuta en el simulador se convierte en zombie. Esto suena como una secuencia de apagado impuro.

En una corazonada en lugar de presionar "Detener", detuve la aplicación, y en la consola de depuración (LLDB en mi caso) me desconecté de la aplicación en ejecución usando "desprendimiento de procesos". Un ps rápido verifica que debugserver ya no se está ejecutando ... ¡hasta ahora todo bien! Ahora, la aplicación todavía se está ejecutando en el simulador, pero no bajo depuración. De hecho, pulsar el botón Detener ahora es un no-op.

En el simulador, pulsa el botón de inicio para volver al trampolín, luego haz doble clic en el botón de inicio y cierra la aplicación manualmente. Ve a tu línea de comando y busca al zombie ... ¡no zombie! Hurra.

Entonces ... el siguiente paso es ver si hay una manera razonable de ejecutar este o un procedimiento de apagado similar a través de un script de Python, etc. ''Curso que no ayuda si estás en GDB. Si puedo hacer un cierre limpio a través de un solo comando de la consola de depuración, entonces solo es cuestión de acostumbrarme a no presionar el botón Detener roto. Tal vez hay un recurso hackeado para deshabilitarlo por completo ... :)

EDITAR # 1: par de tidbits interesantes ...

1.) Al presionar el botón Detener en xcode, simplemente se eliminan los procesos de depuración y aplicación, no hay ningún intento de hacer un cierre limpio en absoluto. La depuración de Printf en la aplicación delegada applicationWillTerminate y applicationDidEnterBackground muestra que la aplicación en ejecución muere con prejuicios, no se muestran NSLogs en la consola.

2.) En la consola de depuración, llamar a [UIApplication terminateWithSuccess] hará que la aplicación finalice "correctamente", pero aún deja un zombie ... curiosamente, si tiene un conjunto de puntos de interrupción, la aplicación no terminará:

(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) 

Así que la aplicación pasa por algún tipo de proceso de apagado, y la aplicación terminará en la consola, pero todavía tenemos un zombi, por lo que todavía no es un cierre limpio.

Estoy pensando que todo esto tiene que ver con que la aplicación pase a segundo plano dentro del tiempo de ejecución de iOS. Al mungear los procesos directamente (mediante el botón Detener, comando kill, cosas de la consola de depuración, etc., etc.), el tiempo de ejecución de iOS no tiene permitido realizar el apagado y la limpieza adecuados; de hecho, Springboard aún piensa que la aplicación se ejecuta en segundo plano, incluso cuando El proceso ya no existe. Da la casualidad de que nuestros tiempos de ejecución de iOS y OS X son iguales, por lo tanto, el propietario es el zombi.

Así que creo que la solución a todo esto es determinar un procedimiento de cierre limpio en el nivel de iOS y, al menos, poder ejecutarlo a través de la consola de depuración. Voy a ver más en el indicador UIApplicationExitsOnSuspend, a ver si puedo establecer los bits necesarios en tiempo de ejecución (a diferencia de plist) para obtener el cierre de la aplicación limpiamente al separar la depuración ...

Answer 2

En particular, no ocupan mucho espacio.

Esto parece ser un artefacto de la maquinaria Xcode que mata incorrectamente a los subprocesos.

Tengo el mismo problema, pero observo que los zombies pertenecen, en mi caso, a ppid 271, que es una invocación de launchd bajo mi nombre, en lugar de todo el sistema.

Tengo curiosidad por lo que podría suceder si mato o elimino ese proceso.

En cualquier caso, desconectarse probablemente borrará a los zombies . Y ciertamente reiniciará, pero eso debe evitarse, en mi libro.

Oh, eso fue bastante mal . No interrumpa su lanzamiento , mata sin ceremonias su sesión, pero no hace nada para permitirle recuperarla, como para darle una pantalla de inicio de sesión.

Tendré que mirar y ver si dejé atrás a los zombies porque detuve Xcode. Parece que podría haber un par de cosas tontas aquí. Si tu proceso no espera a un niño, se vuelve zombi. Si el padre muere, lo siguiente en la línea lo consigue, creo, que en este caso es launchd. Launchd debería esperar () por eso, pero ¿quizás eso se confunda?