[Mono-bugs] [Bug 537764] Mono crashes on OS X Snow Leopard

[bugzilla_noreply at novell.com]

http://bugzilla.novell.com/show_bug.cgi?id=537764

User laurent.etiemble at gmail.com added comment
http://bugzilla.novell.com/show_bug.cgi?id=537764#c9


Laurent Etiemble <laurent.etiemble at gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |laurent.etiemble at gmail.com




--- Comment #9 from Laurent Etiemble <laurent.etiemble at gmail.com>  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.