[Mono-bugs] [Bug 55131][Nor] Changed - Thread.Abort() is causing a crash

bugzilla-daemon@bugzilla.ximian.com bugzilla-daemon@bugzilla.ximian.com
Wed, 31 Mar 2004 14:14:36 -0500 (EST)

Please do not reply to this email- if you want to comment on the bug, go to the
URL shown below and enter your comments there.

Changed by vargaz@freemail.hu.


--- shadow/55131	2004-03-31 13:45:01.000000000 -0500
+++ shadow/55131.tmp.20182	2004-03-31 14:14:36.000000000 -0500
@@ -97,6 +97,30 @@
 Unfortunately I can't find any gcc documentation for this feature.
+------- Additional Comments From vargaz@freemail.hu  2004-03-31 14:14 -------
+The problem here is that the __frame_state_for () function, which is
+in glibc, can't handle the stack frame of pthread_cond_wait for some
+reason so it crashes. The solution is to get rid of the 
+MONO_USE_EXC_TABLES stuff, which is a giant hack.
+An alternative soluation would be to handle async exceptions like
+Thread.Abort differently when the receiving thread is in native code.
+The current solution does not really work, since the thread can be
+in _any_ state when receiving the signal, it can hold unmanaged locks,
+it can be inside functions which are not async signal safe, like
+GC_malloc etc. An alternative would be to note the signal somewhere,
+let execution continue, then raise the exception when control 
+returns to managed code. That would solve all the weird problems with