Bug 6383 - ConnectFailure (System Call Failed) in HttpWebRequest
Summary: ConnectFailure (System Call Failed) in HttpWebRequest
Alias: None
Product: iOS
Classification: Xamarin
Component: XI runtime ()
Version: 5.2
Hardware: Other Other
: --- normal
Target Milestone: Untriaged
Assignee: Bugzilla
Depends on:
Reported: 2012-08-03 14:57 UTC by Paul Seabury
Modified: 2013-12-05 18:34 UTC (History)
5 users (show)

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

Screenshot_Stacktrace (649.30 KB, image/png)
2012-08-08 11:57 UTC, Paul Seabury

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 Developer Community or GitHub 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:

Description Paul Seabury 2012-08-03 14:57:48 UTC
See :

Method 1 - Consume an old-style webservice in MonoTouch
1 - http://stackoverflow.com/questions/10217875/monotouch-webservice-fails-after-some-number-of-requests-with-connectfailure-s

Method 2 - ServiceStack-based Client / Sever
2 - http://monotouch.2284126.n4.nabble.com/ConnectFailure-error-causes-app-to-cease-connecting-externally-td3931899.html#none

Once the network stack gets into this state, no network calls (this webservice client or others in the app) will successfully connect ever again.  It might be that the socket held by the ServicePoint in the ServicePointManager for this host is hosed and the SPM will never get rid of it (nor can you force it to), or it may be some other reason altogether.

Comment 1 Rolf Bjarne Kvinge [MSFT] 2012-08-04 16:13:56 UTC
Do you have a test case I can use to reproduce this?
Comment 2 Paul Seabury 2012-08-08 11:57:44 UTC
Created attachment 2328 [details]

I still haven't gotten a self-contained test case to be able to reproduce this for you, but I can easily reproduce it in my original App.  It's possible that this is enough to at least start taking a look at how WebConnection.Ctor -> InitConnection might be improved to recover from this state (never can connect again) though.
Comment 3 Paul Seabury 2012-08-10 12:01:29 UTC
Is there any way for me to see &| debug the Socket_internal(AddressFamily family, SocketType type, ProtocolType proto, out int error) implementation?  

It is this call which is returning error code 10107 (System call failed) when the ServicePoint calls WebConnection.InitConnection(...).
Comment 4 Rolf Bjarne Kvinge [MSFT] 2012-08-10 12:11:48 UTC
You can attach gdb to the simulator process to debug native code.

You can get the source code for the mono runtime here: https://github.com/mono/mono (you need the 2-10 branch, and have in mind the actual runtime we use is slightly different (this would mean that any line numbers may be off. It is unlikely that you'll into this when debugging sockets though)).
Comment 6 Jeff 2013-05-10 18:35:44 UTC
Hey, I'm seeing this issue as well. I'm able to reproduce this after running a few dozen requests. Has any progress been made on this bug? Are there any known workarounds?
Comment 7 Rolf Bjarne Kvinge [MSFT] 2013-05-10 19:14:00 UTC
Jeff, can you attach a test project I can use to reproduce it?
Comment 8 Brett Nagy 2013-06-23 17:43:44 UTC
I'm seeing this issue too. I'm on the latest stable of Xamarin Studio, Mono and Xamarin.iOS.

I have tried creating a consistently failing test case, but cannot get the error in this way.

It must say something that if I make HTTP calls in a loop, within a test case, I cannot force the error. If I interact with my app (making HTTP calls), I get this error after just a few minutes.
Comment 9 Brett Nagy 2013-07-07 22:05:30 UTC
Is anyone in this thread using SQL Lite?

I have a way to reproduce this issue 100% of the time, in an automated fashion, using my real app. In that test run, if I comment out my calls to SQL Lite I never see this issue. I have triple checked I am closing SQL Lite connections and disposing all objects by the book.

Are these two technologies related in some way? Is this a red herring?
Comment 10 Brett Nagy 2013-07-08 14:47:08 UTC
The SQLite theory seems to be borne out:


Rolf, any idea what exactly is causing this and if there is a workaround? Having to rip out SQLite from my app is going to be a major pain.

Comment 11 Rolf Bjarne Kvinge [MSFT] 2013-07-15 08:57:54 UTC
Brett: unfortunately I have no idea what might be going on, I'd really need some way to reproduce it in order to look into it.

Note that a test case can be your own app (you can send it to us privately). I'd only ask that I don't have to click around for half an hour before the problem shows up (you said you can't reproduce it by making HTTP calls in a loop - but can you simulate user interaction so that it's reproducible by just starting the app and waiting for a while?)
Comment 12 Brett Nagy 2013-07-15 18:51:00 UTC
Hi Rolf,

I do have an app that will generate the error without human interaction. I will sent the download link to your xamarin.com email address. It will take me 24-48hrs to get that together.

Thank you for the reply.

Comment 13 PJ 2013-11-19 17:04:11 UTC
This bug has been in the NEEDINFO state with no changes for the last 90 days. Can we put this back into the NEW or CONFIRMED state, or are we still awaiting response?

If there is no change in the status of this bug over the next two weeks, this bug will be marked as NORESPONSE.
Comment 14 PJ 2013-12-05 18:34:11 UTC
This bug has not been changed from the NEEDINFO state since my previous comment, marking as RESOLVED NORESPONSE.

Please feel free to REOPEN this bug at any time if you are still experiencing the issue. Please add the requested information and set the bug back to the NEW (or CONFIRMED) state.