http://bugzilla.novell.com/show_bug.cgi?id=537764
User [email protected] added comment http://bugzilla.novell.com/show_bug.cgi?id=537764#c9 Laurent Etiemble <[email protected]> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |[email protected] --- Comment #9 from Laurent Etiemble <[email protected]> 2009-09-29 13:25:46 MDT --- I have done some tests with a lot of debug statements on both Leopard and Snow Leopard, to compare the behavior of the foreign thread registration/deregistration. On Leopard (Mac OS X 10.5): - Before the run loop start, there is 3 threads (one is the main one) id=0xb0187000 (flags=2) id=0xb0081000 (flags=2) id=0xa0745720 (flags=6) - After the run loop start, there is still 3 threads id=0xb0187000 (flags=2) id=0xb0081000 (flags=2) id=0xa0745720 (flags=6) - When clicking on the button, a foreign thread is registered with the GC id=0xb022d000 (flags=8) <- New foreign thread id=0xb0187000 (flags=2) id=0xb0081000 (flags=2) id=0xa0745720 (flags=6) - When the GC is invoked, the thread_get_state function return KERN_SUCCESS for all the threads - The foreign thread keeps registered with the GC, and is never deregistered. On Snow Leopard (Mac OS X 10.6): - Before the run loop start, there is 3 threads (one is the main one) id=0xb0187000 (flags=2) id=0xb0081000 (flags=2) id=0xa0af4500 (flags=6) - After the run loop start (shortly after), some foreign threads are registered with the GC id=0xb0398000 (flags=8) <- New foreign thread id=0xb0187000 (flags=2) id=0xb0081000 (flags=2) id=0xa0af4500 (flags=6) .. id=0xb0316000 (flags=8) <- New foreign thread id=0xb0398000 (flags=8) id=0xb0187000 (flags=2) id=0xb0081000 (flags=2) id=0xa0af4500 (flags=6) - After a few seconds, some foreign threads are either registered or deregistered. The whole process does not seems to follow a pattern. id=0xb0398000 (flags=8) id=0xb0187000 (flags=2) id=0xb0081000 (flags=2) id=0xa0af4500 (flags=6) .. id=0xb0316000 (flags=8) <- New foreign thread (hey, we've seen it before !!!) id=0xb0398000 (flags=8) id=0xb0187000 (flags=2) id=0xb0081000 (flags=2) id=0xa0af4500 (flags=6) .. id=0xb0316000 (flags=8) id=0xb0187000 (flags=2) id=0xb0081000 (flags=2) id=0xa0af4500 (flags=6) .. id=0xb0398000 (flags=8) <- New foreign thread (hey, we've seen it before !!!) id=0xb0316000 (flags=8) id=0xb0187000 (flags=2) id=0xb0081000 (flags=2) id=0xa0af4500 (flags=6) - When clicking on the button, the thread_get_state function fails on the first foreign thread with the return value 0x10000003 (Note that KERN_NO_SPACE is defined as 0x3, so I don't really know if it a combination of return values or something else) Some Points: - On Snow Leopard, it seems that there is some kind of "yoyo effect" in the registration and deregistration of foreign threads (sometimes the same thread got registered/deregistered several times). I don't have a sufficient knowledge of the Mach kernel and the libgc to clearly see how and why it happens. - The same foreign thread (same thread_id and same mach_thread_id) got registered and then deregistered, with no visible reason (no user action) - When a foreign thread is registered in the GC, a thread_get_state is not guaranteed to be successful. And when the function fails, the abort call crash the application. - I would suggest to adapt the previous patch to mark foreign thread as STALLED (new state) instead of FINISHED if the thread_get_state function fails. This way, a foreign thread marked as STALLED would still have a chance to be deregistered in a clean way without any leak (removal from the GC_thread table and deallocation of the mach_port). Any thoughts ? -- 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
