[Mono-bugs] [Bug 82658][Nor] Changed - Mono segfaults when using Console.CancelKeyPress and TcpListener.BeginAcceptTcpClient

[bugzilla-daemon at 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 lupus at ximian.com.

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

--- shadow/82658	2007-09-01 13:02:49.000000000 -0400
+++ shadow/82658.tmp.21618	2007-09-03 05:59:35.000000000 -0400
@@ -63,6 +63,88 @@
     }
 }
 
 ------- Additional Comments From vargaz at gmail.com  2007-09-01 13:02 -------
 I can't repro this using SVN HEAD.
 
+
+------- Additional Comments From lupus at ximian.com  2007-09-03 05:59 -------
+I got his:
+** ERROR **: file marshal.c: line 3076 (mono_marshal_find_in_cache):
+assertion failed: (ret == 0)
+or this:
+** ERROR **: file marshal.c: line 4885
+(mono_marshal_get_runtime_invoke): assertion failed: (ret == 0)
+or this:
+** ERROR **: file error.c: line 70 (SetLastError): assertion failed:
+(ret == 0)
+or this:
+** ERROR **: file marshal.c: line 3090 (mono_mb_create_and_cache):
+assertion failed: (ret == 0)
+or:
+Segmentation fault
+(with no further info).
+
+At one point I got:
+
+** ERROR **: file critical-sections.c: line 95
+(DeleteCriticalSection): assertion failed: (ret == 0)
+aborting...
+Stacktrace:
+
+
+(bug-82658.exe:27855): GLib-CRITICAL **: g_hash_table_insert:
+assertion `hash_table->ref_count > 0' failed
+
+(bug-82658.exe:27855): GLib-CRITICAL **: g_hash_table_insert:
+assertion `hash_table->ref_count > 0' failed
+
+(bug-82658.exe:27855): GLib-CRITICAL **: g_hash_table_insert:
+assertion `hash_table->ref_count > 0' failed
+
+(bug-82658.exe:27855): GLib-CRITICAL **: g_hash_table_insert:
+assertion `hash_table->ref_count > 0' failed
+  at (wrapper managed-to-native) System.Environment.Exit (int) <0x00004>
+  at (wrapper managed-to-native) System.Environment.Exit (int)
+<0xffffffff>
+  at System.Console.DoConsoleCancelEvent () <0x0010d>
+  at (wrapper delegate-invoke) System.MulticastDelegate.invoke_void ()
+<0xffffffff>
+  at (wrapper runtime-invoke)
+InternalCancelHandler.runtime_invoke_void
+(object,intptr,intptr,intptr) <0xffffffff>
+
+Native stacktrace:
+
+        mono [0x816c51f]
+        [0xffffe440]
+        /lib/i686/cmov/libc.so.6(abort+0x101) [0xb7d5d171]
+        /usr/lib/libglib-2.0.so.0(g_logv+0x459) [0xb7ef09f9]
+        /usr/lib/libglib-2.0.so.0(g_log+0x29) [0xb7ef0a39]
+        /usr/lib/libglib-2.0.so.0(g_assert_warning+0x76) [0xb7ef0ab6]
+        mono [0x811236c]
+        mono [0x809a0a9]
+        mono(mono_runtime_cleanup+0x25) [0x80fe5a5]
+        mono [0x8134d5f]
+        mono(mono_runtime_quit+0x23) [0x80fc963]
+        mono [0x80ca935]
+        [0xb701115e]
+        [0xb700f92e]
+        [0xb700f800]
+        [0xb700f769]
+        mono(mono_runtime_invoke_array+0x1a5) [0x8106465]
+        mono [0x81069dd]
+        mono [0x80d5bf3]
+        mono [0x80d72cd]
+        mono [0x80f0d14]
+        mono [0x8117562]
+        mono [0x812c1d5]
+        /lib/i686/cmov/libpthread.so.0 [0xb7ea346b]
+        /lib/i686/cmov/libc.so.6(clone+0x5e) [0xb7e044ce]
+
+The main issue here is that we somehow bring down the runtime while
+there is still some thread running: once the critical sections are
+freed, we get the asserts.
+There is another issue which could cause some of the issues: the
+SIGINT handler in console-io.c takes locks and does quite a few
+operations that are ultimately unsafe to do in a signal context.
+