http://bugzilla.novell.com/show_bug.cgi?id=537764
User [email protected] added comment http://bugzilla.novell.com/show_bug.cgi?id=537764#c13 --- Comment #13 from Sledge Ham <[email protected]> 2009-10-04 05:11:24 MDT --- hmmm... it gets interesting when I break on GC_thread_register_foreign just after setting the me-variable (so you can read out the me variable in gdb) Is anyone able to explain the following stack trace? Thread 8 (process 64873): #0 GC_thread_register_foreign (base_addr=0xb0397a94) at pthread_support.c:1364 #1 0x000fc0b3 in mono_gc_register_thread (baseptr=0xb0397a94) at boehm-gc.c:218 #2 0x001afae1 in mono_thread_attach (domain=0x616e58) at threads.c:813 #3 0x000067a2 in mono_jit_thread_attach (domain=0x616e58) at mini.c:2128 #4 0x00779295 in ?? () #5 0x91d6f53c in -[NSConcreteNotification dealloc] () #6 0x91d6fdae in __NSFinalizeThreadData () #7 0x933eba1d in _pthread_tsd_cleanup () #8 0x933eb5ca in _pthread_exit () #9 0x91d7a984 in +[NSThread exit] () #10 0x91d7a92c in __NSThread__main__ () #11 0x933e2f39 in _pthread_start () #12 0x933e2dbe in thread_start () In this stacktrace I read that a separate thread is being stopped (_pthread_exit), hoewever while cleaning up some thread specific data this thread is being picked up (again?) to be added in the GC_threads-array, which results in the crash... I think we should look at why we end up in this situation and fix this.. If this is fixed we can probably get rid of the patch in the darwin_stop_world.c Anyone a good idea how we could test if the cleanup is started to prevent adding this thread again to the GC_threads-table? Maybe we should add a thread specific data which says that this thread is about to go dead. -- Configure bugmail: http://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug. _______________________________________________ mono-bugs maillist - [email protected] http://lists.ximian.com/mailman/listinfo/mono-bugs
