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

[bugzilla-daemon@bugzilla.ximian.com]

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.

http://bugzilla.ximian.com/show_bug.cgi?id=55131

--- 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
+Thread.Abort.
+
+
+
+
+
+
+
+
+