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
> [...]
>

Reply via email to