2010-02-11 16 views
5

Hola a todos, estoy en el proceso de depurar una aplicación C++ en mac os 10.5. Ocasionalmente, haré algo malo y causaré un segfault o una operación que de otra manera sería ilegal. Esto da como resultado la suspensión de la aplicación por un tiempo y, finalmente, un cuadro de diálogo del sistema que me notifica del bloqueo. El tiempo de espera entre el "hang" y el diálogo es significativo; unos minutos. Si trato de forzar a salir de la aplicación o kill -9 desde la línea de comandos no pasa nada. Si inicio la aplicación desde el depurador (gdb), al producirse un bloqueo, vuelvo al indicador gdb y puedo salir del proceso limpiamente. Sin embargo, eso no es ideal ya que gdb tarda en cargarse.Depuración y eliminación de aplicaciones en Mac OS X?

De todos modos, ¿pueden recomendar algo? ¿Hay alguna forma de desactivar el mecanismo de informe de bloqueo en OS X?

Gracias.

Actualización 1: Aquí están los zombies que sobran de una ejecución XCode. Aparentemente, xcode tampoco puede detenerlos correctamente.

 1 [email protected]:~$ ps auxw|grep -i Reader 
    2 eightieight 28639 0.0 0.0 599828 504 s004 R+ 2:54pm 0:00.00 grep -i reader 
    3 eightieight 28288 0.0 1.1 1049324 45032 ?? UEs 2:46pm 0:00.89 /Users/eightieight/workspace/spark/spark/reader/browser/build/Debug/Reader.app/Contents/MacOS/Reader 
    4 eightieight 28271 0.0 1.1 1049324 45036 ?? UEs 2:45pm 0:00.89 /Users/eightieight/workspace/spark/spark/reader/browser/build/Debug/Reader.app/Contents/MacOS/Reader 
    5 eightieight 28146 0.0 1.1 1049324 44996 ?? UEs 2:39pm 0:00.90 /Users/eightieight/workspace/spark/spark/reader/browser/build/Debug/Reader.app/Contents/MacOS/Reader 
    6 eightieight 27421 0.0 1.1 1049328 45024 ?? UEs 2:29pm 0:00.88 /Users/eightieight/workspace/spark/spark/reader/browser/build/Debug/Reader.app/Contents/MacOS/Reader 
    7 eightieight 27398 0.0 1.1 1049324 45044 ?? UEs 2:28pm 0:00.90 /Users/eightieight/workspace/spark/spark/reader/browser/build/Debug/Reader.app/Contents/MacOS/Reader 
+0

¿Está utilizando XCode? Si es así, no debería estar viendo el cuadro de diálogo Crash Reporter. Además, ¿está creando una aplicación basada en GUI o simplemente una aplicación de consola? Edición: por cierto, en caso de que esté utilizando XCode, si obtiene un error EXEC_BAD_ACCESS mientras ejecuta una aplicación GUI en XCode, puede simplemente presionar el icono de detener para finalizar inmediatamente la aplicación en ejecución. – Tom

+0

Sí, si ejecuto mis aplicaciones dentro de XCode o gdb, todo funciona correctamente. Cuando recibo un segfault, la aplicación regresa al depurador y todo es genial. Sin embargo, si ejecuto la aplicación desde la consola, parece colgar para siempre. – EightyEight

+0

¿Cómo invoca la aplicación?Normalmente, si una aplicación se cae con dificultad, el juego se acaba, el proceso está muerto. Sin embargo, si ha logrado invocarlo desde otro entorno, tal vez algunos recursos para ese proceso se mantienen abiertos y todavía no puede dejarlo ir y está esperando que el proceso principal haga algo primero (y puede tener el problema de detectar algo salió mal). –

Respuesta

1

Ahí está el CrashReporterPrefs app que viene con XCode (buscar con Spotlight; debe estar en /Developer/Applications/Utilities). Eso puede ser configurar el modo de servidor para desactivar el diálogo de la aplicación 'Inesperadamente salir'.

Aquí es another suggestion:

sudo chmod 000 /System/Library/CoreServices/Problem\ Reporter.app 

para volver a habilitar, haga lo siguiente:

sudo chmod 755 /System/Library/CoreServices/Problem\ Reporter.app 

Podría ser que la aplicación está descargando un archivo de gran núcleo - que probablemente se daría cuenta el efecto en el espacio de disco disponible sin embargo. Puede apagar núcleo vertido utilizando

sudo sysctl -w kern.coredump=0 

Reactivar estableciendo =1.

+0

Sí, lo intenté ya. El cuadro de diálogo ya no emerge, pero aún hay retraso. – EightyEight

+0

No recomendaría el enfoque 'chmod'. La modificación de los archivos del sistema o permisos está causando problemas. La aplicación Prefs hará lo que le pidas. – gavinb

+0

@gavinb - acordado; sugerencias reordenadas –

1

This article de osxdaily.com dice que sólo tiene que escribir:

defaults write com.apple.CrashReporter DialogType none

en el terminal. No sé si eso arreglará el retraso sin embargo.

1

Finalmente lo descubrí.

en/System/Library/CoreServices:

 
---------- 1 root wheel 56752 11 Aug 2009 ReportPanic 

Eso debe haber sido de mis intentos anteriores para desactivar el cuadro de diálogo informe molesto. Vive y aprende. :]