Ah good news. This crash was caused by infinite recursion in my code. It wasn't obvious from the trace but luckily I was able to stumble on a repro.
--Anthony On Sun, May 16, 2010 at 11:55 PM, Laurent Etiemble <laurent.etiem...@monobjc.net> wrote: > Hello, > Have you tried to make a small test-case application that would be easy to > debug ? > Maybe a small Cocoa application, with an event loop (as in thread-0) and > some worker threads that create strings, split them and call GC would do the > trick. > Regards, Laurent Etiemble. > > 2010/5/15 anthony taranto <anthony.tara...@gmail.com> >> >> I'm experiencing an intermittent crash with my multi-threaded monobjc >> application on OSX 10.6 Snow Leopard. There doesn't seem to be any >> reliable sequence of user interaction that triggers this crash, but >> the crash dumps all show a similar pattern: EXC_CRASH in thread 0 >> while another thread is executing a managed garbage collection after a >> String.Split(). Example follows. I'm not sure what an appropriate fix >> or workaround to this problem is. Any help is greatly appreciated. >> >> >> Exception Type: EXC_CRASH (SIGILL) >> Exception Codes: 0x0000000000000000, 0x0000000000000000 >> Crashed Thread: 0 Dispatch queue: com.apple.main-thread >> >> Thread 0 Crashed: Dispatch queue: com.apple.main-thread >> 0 libSystem.B.dylib 0x92b6d2fa mach_msg_trap + 10 >> 1 libSystem.B.dylib 0x92b6da67 mach_msg + 68 >> 2 com.apple.CoreFoundation 0x9945d00f __CFRunLoopRun + 2079 >> 3 com.apple.CoreFoundation 0x9945c0f4 CFRunLoopRunSpecific + 452 >> 4 com.apple.CoreFoundation 0x9945bf21 CFRunLoopRunInMode + 97 >> 5 com.apple.HIToolbox 0x97ada0fc RunCurrentEventLoopInMode + >> 392 >> 6 com.apple.HIToolbox 0x97ad9eb1 ReceiveNextEventCommon + >> 354 >> 7 com.apple.HIToolbox 0x97ad9d36 >> BlockUntilNextEventMatchingListInMode + 81 >> 8 com.apple.AppKit 0x97e12135 _DPSNextEvent + 847 >> 9 com.apple.AppKit 0x97e11976 -[NSApplication >> nextEventMatchingMask:untilDate:inMode:dequeue:] + 156 >> 10 com.apple.AppKit 0x97dd3bef -[NSApplication run] + 821 >> 11 ??? 0x14b5cdda 0 + 347459034 >> 12 ??? 0x14b5cd04 0 + 347458820 >> 13 ??? 0x14b5cc96 0 + 347458710 >> 14 ??? 0x14b5cc76 0 + 347458678 >> 15 ??? 0x020bc1f2 0 + 34324978 >> >> [...] >> >> Thread 13: >> 0 libmono.0.dylib 0x018a9ae4 GC_clear_stack_inner + 22 >> (misc.c:295) >> 1 libmono.0.dylib 0x018a9b15 GC_clear_stack_inner + 71 >> (misc.c:301) >> 2 libmono.0.dylib 0x018a9b15 GC_clear_stack_inner + 71 >> (misc.c:301) >> 3 libmono.0.dylib 0x018a9b15 GC_clear_stack_inner + 71 >> (misc.c:301) >> 4 libmono.0.dylib 0x018a9b15 GC_clear_stack_inner + 71 >> (misc.c:301) >> 5 libmono.0.dylib 0x018a9b15 GC_clear_stack_inner + 71 >> (misc.c:301) >> 6 libmono.0.dylib 0x018a9b15 GC_clear_stack_inner + 71 >> (misc.c:301) >> 7 libmono.0.dylib 0x018a9b15 GC_clear_stack_inner + 71 >> (misc.c:301) >> 8 libmono.0.dylib 0x018a9b15 GC_clear_stack_inner + 71 >> (misc.c:301) >> 9 libmono.0.dylib 0x018a9b15 GC_clear_stack_inner + 71 >> (misc.c:301) >> 10 libmono.0.dylib 0x018a9bc1 GC_clear_stack + 153 >> (misc.c:343) >> 11 libmono.0.dylib 0x018a5484 GC_malloc_atomic + 150 >> (malloc.c:262) >> 12 libmono.0.dylib 0x018114dd >> mono_object_allocate_ptrfree + 46 (object.c:3824) >> 13 libmono.0.dylib 0x018117fb mono_string_new_size + 146 >> (object.c:4395) >> 14 libmono.0.dylib 0x018407b5 >> ves_icall_System_String_InternalSplit + 921 (string-icalls.c:145) >> 15 ??? 0x164849b6 0 + 373836214 >> [...] > >
