2010-02-11 15 views
5

Ciao a tutti, sto eseguendo il debug di un'applicazione C++ su mac os 10.5. Occasionalmente, farò qualcosa di negativo e causerò un segfault o un'operazione altrimenti illegale. Ciò comporta l'app in sospeso per un po 'e infine una finestra di dialogo di sistema che mi avvisa del crash. Il tempo di attesa tra "blocco" e finestra di dialogo è significativo; pochi minuti. Se provo a forzare l'uscita dall'applicazione o kill -9 dalla riga di comando, non succede nulla. Se avvio l'app dal debugger (gdb), in caso di crash torno al prompt di gdb e posso uscire in modo pulito dal processo. Questo non è l'ideale anche se gdb è lento da caricare.Debug e uccisione di app su Mac OS X?

In ogni caso, potete consigliare qualcosa? C'è un modo per disattivare il meccanismo di segnalazione degli arresti anomali in OS X?

Grazie.

Aggiornamento 1: Ecco gli zombi che vengono lasciati da un'esecuzione XCode. Apparentemente xcode non può fermarli correttamente neanche.

 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

Stai usando XCode? In tal caso, non dovresti visualizzare la finestra di dialogo Crash Reporter. Inoltre, stai costruendo un'applicazione basata su GUI o solo un'applicazione di console? Modifica: casualmente, nel caso in cui si utilizzi XCode, se si verifica un errore EXEC_BAD_ACCESS durante l'esecuzione di un'app GUI in XCode, è sufficiente premere l'icona di arresto per terminare immediatamente l'app in esecuzione. – Tom

+0

Sì, se eseguo le mie app in XCode o gdb, tutto funziona correttamente. Quando ottengo un segfault, l'app ritorna nel debugger e tutto è ottimo. Tuttavia, se eseguo l'app dalla console, sembra che si blocchi per sempre. – EightyEight

+0

Come stai invocando l'app?In genere, se un'app si blocca, game over, il processo è morto. Tuttavia, se sei riuscito a invocarlo da qualche altro ambiente, forse alcune risorse per quel processo sono tenute aperte e non possono lasciarlo andare ancora e stai aspettando che il processo genitore faccia qualcosa per primo (e potrebbe avere il problema di scoprire che qualcosa è andato storto). –

risposta

1

C'è il CrashReporterPrefs app che viene fornito con XCode (cercare con Spotlight, dovrebbe essere in /Developer/Applications/Utilities). Ciò può essere impostato su Modalità server per disabilitare anche la finestra di dialogo "Chiudi inaspettatamente" dell'applicazione.

Ecco another suggestion:

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

Per riattivare, effettuare le seguenti operazioni:

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

Potrebbe essere che l'applicazione è di dumping un file di grandi dimensioni di base - si sarebbe probabilmente notato l'effetto sullo spazio disponibile su disco però. È possibile spegnere nucleo dumping utilizzando

sudo sysctl -w kern.coredump=0 

Riattivare modificando =1.

+0

Sì, ci ho già provato. La finestra di dialogo non è più popup ma c'è ancora il ritardo .. – EightyEight

+0

Non consiglierei l'approccio 'chmod'. La modifica dei file di sistema o delle autorizzazioni richiede problemi. L'app Prefs farà quello che chiedi. – gavinb

+0

@gavinb - concordato; suggerimenti riordinati. –

1

This article da osxdaily.com dice basta digitare:

defaults write com.apple.CrashReporter DialogType none

nel terminale. Non so se questo risolverà il ritardo.

1

Finalmente ho capito.

in/System/Library/CoreServices:

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

Deve essere stato dai miei precedenti tentativi di disattivare la finestra di segnalazione fastidioso. Vivere e imparare. :]