¿Cómo puedo depurar un accidente cuando corro mi aplicación recolección de basura en Rosetta?

Question

Tengo una aplicación universal que se dirige a 10.5 y que utiliza la recolección de basura. Estoy construyendo para ppc, i386 y x86_64.

No tengo acceso a una máquina PowerPC física, así que estoy tratando de usar Rosetta Para confirmar que la porción PowerPC de la aplicación funciona correctamente.

Sin embargo, tan pronto como se inició la aplicación de Rosetta se bloquea inmediatamente con el siguiente registro de bloqueo:

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

he utilizado la documentación de Apple sobre la depuración de aplicaciones traducidas y la información sobre esta página adjuntar gdb a la aplicación cuando se está ejecutando en Rosetta. La aplicación inmediatamente se rompe en el depurador en el lanzamiento:

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) 

No tengo idea de por dónde empezar con esto. Parece que el recolector de basura está fallando muy mal. Se aplicaciones PowerPC recolección de basura no se admiten en Rosetta? No puedo ver ninguna mención de esta limitación en la documentación si es así.

¿Alguien tiene alguna idea?

Answer 1

Ahora he determinado que las aplicaciones PowerPC recolección de basura no se pueden ejecutar con Rosetta. Después de escarbar en Google me encontré con un par de menciones sobre este tema en la lista de correo Cacao-Dev, aunque no hay nada "oficial" de Apple.

Me han confirmado que incluso la aplicación por defecto plantilla de aplicación de cacao se bloqueará inmediatamente si compilado para ppc con la recolección de basura y luego puesto en marcha bajo Rosetta.

debo decir que es muy frustrante que no hay ninguna mención de esta limitación, ya sea en el Programación binario universal Directrices (que discuten Rosetta), la Garbage Collection Guía de Programación o las notas de la versión AppKit Leopard o Fundación. También es frustrante que el tiempo de ejecución no genera algún tipo de mensaje de error útiles.

Como leopardo / Rosetta / PowerPC son ahora "tecnologías de legado" No creo que la presentación de un fallo en contra de esta omisión va a hacer mucho bien, pero espero que esta respuesta le ayudará a aquellos que vienen en contra de la misma cuestión.

Answer 2

Una manera de probarlo es desactivar el recolector de basura cuando se inicia la aplicación.

[[NSGarbageCollector defaultCollector] disable];

Se va a fugas como un loco, pero para una prueba de menor importancia que esto podría funcionar bien. Una advertencia con esto es que usted necesita para asegurarse de que es una de las primeras cosas que suceden en su aplicación. En main sería un lugar bueno, pero si se vincula a los marcos que hacer el trabajo en métodos +load (o tener constructores), puede que tenga que hacerlo en el marco (o interponer una biblioteca en su lugar).