Come faccio il debug di un crash quando eseguo il mio garbage collection app in Rosetta?

Question

Ho un app universale che si rivolge 10.5 e che utilizza garbage collection. Sto costruendo per ppc, i386 e x86_64.

Non ho accesso ad una macchina PowerPC fisico in modo sto cercando di utilizzare Rosetta per confermare che la parte PowerPC della applicazione funziona correttamente.

Tuttavia, non appena l'applicazione viene lanciata in Rosetta si blocca subito con il seguente registro incidente:

Process:         FooApp [91567]
Path:            /Users/rob/Development/src/FooApp/build/Release 64-bit/FooApp.app/Contents/MacOS/FooApp
Identifier:      com.companyX.FooApp
Version:         0.9 (build d540e05) (2)
Code Type:       PPC (Translated)
Parent Process:  launchd [708]

Date/Time:       2010-04-09 18:32:23.962 +1000
OS Version:      Mac OS X 10.6.3 (10D573)
Report Version:  6

Exception Type:  EXC_CRASH (SIGTRAP)
Exception Codes: 0x0000000000000000, 0x0000000000000000
Crashed Thread:  5

...snip non-relevant threads...

Thread 5 Crashed:
0   libSystem.B.dylib               0x8023656a __pthread_kill + 10
1   libSystem.B.dylib               0x80235e17 pthread_kill + 95
2   com.companyX.FooApp         0xb80bfb30 0xb8000000 + 785200
3   com.companyX.FooApp         0xb80c0037 0xb8000000 + 786487
4   com.companyX.FooApp         0xb80dd8e8 0xb8000000 + 907496
5   com.companyX.FooApp         0xb8145397 spin_lock_wrapper + 1791
6   com.companyX.FooApp         0xb801ceb7 0xb8000000 + 118455

Ho usato la documentazione di Apple sul debug di applicazioni tradotte e le informazioni su questa pagina per fissare gdb per l'applicazione quando è in esecuzione in Rosetta. L'applicazione immediatamente si rompe nel debugger sul lancio:

Program received signal SIGTRAP, Trace/breakpoint trap.
[Switching to thread 15107]
0x9151fdd4 in auto_fatal ()
(gdb) bt
#0  0x9151fdd4 in auto_fatal ()
#1  0x91536d84 in Auto::Thread::get_register_state ()
#2  0x915372f8 in Auto::Thread::scan_other_thread ()
#3  0x91529be4 in Auto::Zone::scan_registered_threads ()
#4  0x91539114 in Auto::MemoryScanner::scan_thread_ranges ()
#5  0x9153b000 in Auto::MemoryScanner::scan ()
#6  0x9153049c in Auto::Zone::collect ()
#7  0x915198f4 in auto_collect_internal ()
#8  0x9151a094 in auto_collection_work ()
#9  0x96687434 in _dispatch_call_block_and_release ()
#10 0x9668912c in _dispatch_queue_drain ()
#11 0x96689350 in _dispatch_queue_invoke ()
#12 0x966895c0 in _dispatch_worker_thread2 ()
#13 0x966896fc in _dispatch_worker_thread ()
#14 0x965a97e8 in _pthread_body ()
(gdb) 

Non ho idea da dove cominciare con questo. Sembra che il Garbage Collector sta fallendo molto male. Sono garbage collection applicazioni PowerPC non supportati in Rosetta? Non riesco a vedere alcuna menzione di questa limitazione nei documenti in tal caso.

Qualcuno ha qualche idea?

Answer 1

Ora ho deciso che garbage collection applicazioni PowerPC non possono essere eseguiti utilizzando Rosetta. Dopo aver scavato intorno a Google ho trovato un paio di menzioni su questo sulla mailing list di cacao-Dev, anche se nulla "ufficiale" da parte di Apple.

mi hanno confermato che anche l'applicazione modello di applicazione Cocoa predefinita andrà in crash immediatamente se compilato per PPC con la raccolta dei rifiuti e poi ha lanciato sotto Rosetta.

Devo dire che è estremamente frustrante che non si fa menzione di questa limitazione sia nel Universal Binary Programmazione Linee guida (che discutono Rosetta), il Garbage Collection Programmazione delle note di rilascio Leopard AppKit o fondazione Guida o. E 'anche frustrante che il runtime non genera una sorta di messaggio di errore utile.

Come leopardo / Rosetta / PowerPC sono ora "tecnologie legacy" Io non immagino il deposito di un bug nei confronti di questa omissione farà molto bene, ma spero che questa risposta sarà aiutare coloro che si scontrano con lo stesso problema.

Answer 2

Un modo è possibile verificare è quello di disabilitare il garbage collector all'avvio dell'applicazione.

[[NSGarbageCollector defaultCollector] disable];

Si farà fuoriuscire come un matto, ma per una prova minore questo potrebbe funzionare bene. Un avvertimento di questo è che è necessario fare in modo che si tratta di una delle prime cose che accade nella vostra app. In main sarebbe un buon posto, ma se si collega a quadri che funzionano nei metodi +load (o hanno costruttori), potrebbe essere necessario farlo nel quadro (o interporre un libreria, invece).