Hello, I have been able to reproduce by adding some GC.Collect() call in the code to force the garbage collection. I am still searching what triggers the foreign thread re-registration that lead to the crash.
Thank you for the sample. Regards, Laurent Etiemble. 2010/1/18 Oscar Blasco <oblasco...@gmail.com>: > Hello, > > > > We are currently experiencing random crashes (thread_get_state crash) on > Mono 2.6.1 + Monobjc 2.0.476.0 on Snow Leopard 10.6.2. I have managed to > create a demo application which crashes in the same way as our software > does. The same application on Monobjc 2.0.413.0 and patched Mono 2.4.3 > doesn’t crash (unpatched one does crash though). The main testing computer > was an Xserver running in 64bits mode: > > > > Model Name: Xserve > > Model Identifier: Xserve3,1 > > Processor Name: Quad-Core Intel > Xeon > > Processor Speed: 2.26 GHz > > Number Of Processors: 1 > > Total Number Of Cores: 4 > > L2 Cache (per core): 256 KB > > L3 Cache: 8 MB > > Memory: 3 GB > > > > Crashing thread stacktrace: > > > > Thread 28 Crashed: > > 0 libSystem.B.dylib 0x92bcba4e > __semwait_signal_nocancel + 10 > > 1 libSystem.B.dylib 0x92bcb932 > nanosleep$NOCANCEL$UNIX2003 + 166 > > 2 libSystem.B.dylib 0x92c4739a > usleep$NOCANCEL$UNIX2003 + 61 > > 3 libSystem.B.dylib 0x92c689e5 __abort + 136 > > 4 libSystem.B.dylib 0x92c68a55 abort_report_np + 0 > > 5 GenericCocoaApp 0x001a33a1 GC_enable + 0 > (misc.c:1091) > > 6 GenericCocoaApp 0x0019a9ce GC_push_all_stacks + 196 > (darwin_stop_world.c:127) > > 7 GenericCocoaApp 0x001a46e8 > GC_default_push_other_roots + 11 (os_dep.c:2088) > > 8 GenericCocoaApp 0x001a24aa GC_push_roots + 279 > (mark_rts.c:651) > > 9 GenericCocoaApp 0x0019f861 GC_mark_some + 593 > (mark.c:327) > > 10 GenericCocoaApp 0x0019904c GC_stopped_mark + 525 > (alloc.c:543) > > 11 GenericCocoaApp 0x00198ba5 GC_try_to_collect_inner + > 449 (alloc.c:382) > > 12 GenericCocoaApp 0x001996fe GC_try_to_collect + 144 > (alloc.c:809) > > 13 GenericCocoaApp 0x00199767 GC_gcollect + 26 > (alloc.c:823) > > 14 GenericCocoaApp 0x00085bd7 mono_gc_collect + 36 > (boehm-gc.c:130) > > 15 GenericCocoaApp 0x000a559b > ves_icall_System_GC_InternalCollect + 17 (gc.c:404) > > 16 ??? 0x15dc7a37 0 + 366770743 > > 17 ??? 0x15dc79a4 0 + 366770596 > > 18 ??? 0x15dc7957 0 + 366770519 > > 19 ??? 0x00fd0202 0 + 16581122 > > 20 ??? 0x00c530bf 0 + 12923071 > > 21 GenericCocoaApp 0x001b347e mono_jit_runtime_invoke + > 1306 (mini.c:4691) > > 22 GenericCocoaApp 0x00111652 mono_runtime_invoke + 137 > (object.c:2602) > > 23 GenericCocoaApp 0x00113764 mono_runtime_invoke_array > + 1679 (object.c:3746) > > 24 GenericCocoaApp 0x001164b8 mono_message_invoke + 488 > (object.c:5375) > > 25 GenericCocoaApp 0x00145e4a mono_async_invoke + 164 > (threadpool.c:1015) > > 26 GenericCocoaApp 0x00147802 async_invoke_thread + 327 > (threadpool.c:1443) > > 27 GenericCocoaApp 0x0014910e start_wrapper + 591 > (threads.c:662) > > 28 GenericCocoaApp 0x001888cf thread_start_routine + 201 > (wthreads.c:286) > > 29 GenericCocoaApp 0x001a5b88 GC_start_routine + 106 > (pthread_support.c:1390) > > 30 libSystem.B.dylib 0x92b8bfbd _pthread_start + 345 > > 31 libSystem.B.dylib 0x92b8be42 thread_start + 34 > > > > > > You can find the sample application attached to this email. It shows a > simple window with a few controls, the top button makes the application > crash the second time it’s pressed (not always). The code is a bit messy but > can be easily followed. I have tried making it clearer but it didn’t crash > anymore. Looks like the order the background threads and the > performSelectorOnMainThread calls is the key on making it unstable. > > > > Regards, > > > > Oscar Blasco > Senior Software Developer > Video Stream Networks, S.L. > Telf. +34 96 5993670 > Fax. +34 96 5993673 > obla...@vsn.es > www.vsn-tv.com > >
