[Mono-bugs] [Bug 55131][Nor] Changed - Thread.Abort() is causing a crash
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 firstname.lastname@example.org.
--- 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 email@example.com 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