Bug 44919 - SIGABRT when calling UploadStringTaskAsync on WebClient
Summary: SIGABRT when calling UploadStringTaskAsync on WebClient
Status: RESOLVED FIXED
Alias: None
Product: Runtime
Classification: Mono
Component: io-layer ()
Version: 4.6.0 (C8)
Hardware: PC Linux
: --- normal
Target Milestone: ---
Assignee: Ludovic Henry
URL:
Depends on:
Blocks:
 
Reported: 2016-09-30 09:48 UTC by Dave
Modified: 2016-12-26 23:09 UTC (History)
5 users (show)

Tags:
Is this bug a regression?: ---
Last known good build:


Attachments
System.dll (2.39 MB, application/octet-stream)
2016-10-12 19:34 UTC, Dave
Details


Notice (2018-05-24): bugzilla.xamarin.com is now in read-only mode.

Please join us on Visual Studio Developer Community and in the Xamarin and 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 Links.

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.

Related Links:
Status:
RESOLVED FIXED

Description Dave 2016-09-30 09:48:25 UTC
After updating from Mono 4.4.2 to 4.6.1, the application I am developing started to crash.

I found that the crash is caused by a SIGABRT when UploadStringTaskAsync is called on System.Net.WebClient. The following simple code is all that is needed to reproduce the crash:


---
private async Task<string> UploadStringAsync()
	{
		using (var webClient = new WebClient())
		{
			return await webClient.UploadStringTaskAsync("https://www.google.co.uk", "POST", "stuff");
		}
	}
---


This is a shortened version of the output I get:


* Assertion at socket-io.c:1075, condition `domain->sockaddr_data_field' not met

Stacktrace:

  at <unknown> <0xffffffff>
  at (wrapper managed-to-native) System.Net.Sockets.Socket.Connect_internal (intptr,System.Net.SocketAddress,int&) <IL 0x00009, 0x000bc>
  at System.Net.Sockets.Socket.Connect_internal (System.Net.Sockets.SafeSocketHandle,System.Net.SocketAddress,int&) <IL 0x0000e, 0x000cb>
  at System.Net.Sockets.Socket.Connect (System.Net.EndPoint) <IL 0x00097, 0x00487>
  at System.Net.WebConnection.Connect (System.Net.HttpWebRequest) <IL 0x001a3, 0x00da7>
  at System.Net.WebConnection.InitConnection (object) <IL 0x00046, 0x003b7>
  at System.Net.WebConnection.<WebConnection>m__0 (object) <IL 0x00002, 0x00067>
  at System.Threading.QueueUserWorkItemCallback.WaitCallback_Context (object) [0x0000e] in /builddir/build/BUILD/mono-4.6.1/mcs/class/referencesource/mscorlib/system/threading/threadpool.cs:1304
  at System.Threading.ExecutionContext.RunInternal (System.Threading.ExecutionContext,System.Threading.ContextCallback,object,bool) [0x0008d] in /builddir/build/BUILD/mono-4.6.1/mcs/class/referencesource/mscorlib/system/threading/executioncontext.cs:957
  at System.Threading.ExecutionContext.Run (System.Threading.ExecutionContext,System.Threading.ContextCallback,object,bool) [0x00000] in /builddir/build/BUILD/mono-4.6.1/mcs/class/referencesource/mscorlib/system/threading/executioncontext.cs:904
  at System.Threading.QueueUserWorkItemCallback.System.Threading.IThreadPoolWorkItem.ExecuteWorkItem () [0x0002a] in /builddir/build/BUILD/mono-4.6.1/mcs/class/referencesource/mscorlib/system/threading/threadpool.cs:1281
  at System.Threading.ThreadPoolWorkQueue.Dispatch () [0x00096] in /builddir/build/BUILD/mono-4.6.1/mcs/class/referencesource/mscorlib/system/threading/threadpool.cs:854
  at System.Threading._ThreadPoolWaitCallback.PerformWaitCallback () [0x00000] in /builddir/build/BUILD/mono-4.6.1/mcs/class/referencesource/mscorlib/system/threading/threadpool.cs:1209
  at (wrapper runtime-invoke) <Module>.runtime_invoke_bool (object,intptr,intptr,intptr) <IL 0x0001f, 0x00141>

...

=================================================================
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.
=================================================================


I am running Fedora 24.

Please let me know if you need any more info.
Comment 1 Ludovic Henry 2016-10-03 16:51:50 UTC
@marek it looks like a version mismatch between System.dll and the runtime; how could we check that?
The m_Buffer change was introduced by https://github.com/mono/mono/commit/008f7272d35f93696d5f90ec033eca5989a4697f
Comment 2 Marek Safar 2016-10-04 07:11:49 UTC
Could you attach mono --version output


@ludovic: You mean automatically or for this case only?
Comment 3 Dave 2016-10-05 22:01:59 UTC
$ mono --version
Mono JIT compiler version 4.6.1 (Stable 4.6.1.3/abb06f1 Wed Sep 28 13:22:22 UTC 2016)
Copyright (C) 2002-2014 Novell, Inc, Xamarin Inc and Contributors. www.mono-project.com
        TLS:           __thread
        SIGSEGV:       altstack
        Notifications: epoll
        Architecture:  amd64
        Disabled:      none
        Misc:          softdebug 
        LLVM:          supported, not enabled.
        GC:            sgen
Comment 4 Marek Safar 2016-10-06 07:50:12 UTC
Could you also check you are using System.dll from Mono 4.6.1?
Comment 5 Dave 2016-10-07 21:59:51 UTC
How can I check that?
Comment 6 Marek Safar 2016-10-10 14:03:22 UTC
It's probably the best to attach it to the bug report. Just check it's the one which is actually used
Comment 7 Dave 2016-10-12 19:34:20 UTC
Created attachment 18008 [details]
System.dll

I looked at the references for the project and went to the properties of System.dll, where I found the path to this file.

Assembly version: 4.0.0.0
Package: .NET Framework 4.6.1
Path: /usr/lib/mono/4.5/System.dll
Comment 8 Dave 2016-11-12 21:27:16 UTC
Hi,

Were you able to determine if the System.dll file is the correct one?

Br,
David
Comment 9 Marek Safar 2016-11-25 10:05:52 UTC
That assembly looks ok. Could you try Mono 4.8 we made few changes there which should address this sort of issues as well.
Comment 10 Dave 2016-11-25 23:43:48 UTC
Sure, I can give that a go. Thanks very much for investigating!
Comment 11 Dave 2016-12-26 23:09:48 UTC
Seems to work great now, thanks!