Notice (2018-05-24): bugzilla.xamarin.com is now in
Please join us on
Visual Studio Developer Community and in the
Mono organizations on
GitHub to continue tracking issues. Bugzilla will remain
available for reference in read-only mode. We will continue to work
on open Bugzilla bugs, copy them to the new locations
as needed for follow-up, and add the new items under Related
Our sincere thanks to everyone who has contributed on this bug
tracker over the years. Thanks also for your understanding as we
make these adjustments and improvements for the future.
Please create a new report on
GitHub or Developer Community with
your current version information, steps to reproduce, and relevant error
messages or log files if you are hitting an issue that looks similar to
this resolved bug and you do not yet see a matching new report.
Created attachment 3641 [details]
GDB session / stack trace
Running through a suite of tests using the NUnit 2.6 console runner results in the following. Despite some time trying to pin it down to a specific test it seems it's running the whole suite that causes it. Ironically MD4 handles it better, but I have too managed to get the same error in MD4 test-runner, ironically when using the soft debugger.
(see attached for full information gathered)
Got a SIGABRT while executing native code. This usually indicates
a fatal error in the mono runtime or one of the native libraries
used by your application.
System.Runtime.Remoting.RemotingException: Tcp transport error.
Server stack trace:
at System.Runtime.Remoting.Channels.Tcp.TcpMessageIO.ReceiveMessageStatus (System.IO.Stream networkStream, System.Byte buffer) [0x0000f] in /private/tmp/source/bockbuild/profiles/mono-mac-release/build-root/mono-3.0.6/_build/mono-3.0.6.git/mcs/class/System.Runtime.Remoting/System.Runtime.Remoting.Channels.Tcp/TcpMessageIO.cs:56
at System.Runtime.Remoting.Channels.Tcp.TcpClientTransportSink.ProcessMessage (IMessage msg, ITransportHeaders requestHeaders, System.IO.Stream requestStream, ITransportHeaders& responseHeaders, System.IO.Stream& responseStream) [0x00055] in /private/tmp/source/bockbuild/profiles/mono-mac-release/build-root/mono-3.0.6/_build/mono-3.0.6.git/mcs/class/System.Runtime.Remoting/System.Runtime.Remoting.Channels.Tcp/TcpClientTransportSink.cs:188
at System.Runtime.Remoting.Channels.BinaryClientFormatterSink.SyncProcessMessage (IMessage msg) [0x0006c] in /private/tmp/source
Program received signal EXC_SOFTWARE, Software generated exception.
<signal handler called>
#0 0x93150a6a in __pthread_kill ()
#1 0x99886acf in pthread_kill ()
#2 0x998bd4f8 in abort ()
#3 0x00295ccf in monoeg_g_logv ()
#4 0x00295d21 in monoeg_g_log ()
#5 0x001a847b in lookup_data_table ()
#6 0x001a9975 in mono_debug_remove_method ()
#7 0x00004b32 in mono_jit_free_method ()
#8 0x0020513f in mono_runtime_free_method ()
#9 0x002399a9 in free_dynamic_method ()
#10 0x001ffa83 in reference_queue_proccess ()
#11 0x001ffad5 in reference_queue_proccess_all ()
#12 0x001ff03c in finalizer_thread ()
#13 0x001c1051 in start_wrapper_internal ()
#14 0x001c1172 in start_wrapper ()
#15 0x0026063a in thread_start_routine ()
#16 0x002791d1 in inner_start_thread ()
#17 0x0028f8d8 in GC_start_routine ()
#18 0x99885557 in _pthread_start ()
#19 0x9986fcee in thread_start ()
We would need some kind of testcase to be able to fix this.
As a workaround, you can run mono with -O=-gshared.
Can we get a test case?
Checking with Steven Robbins this evening who also had this issue, I think it's fixed.
*** This bug has been marked as a duplicate of bug 12786 ***