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
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.
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.
Do you have a test case I can use to reproduce this?
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.
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(...).
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)).
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?
Jeff, can you attach a test project I can use to reproduce it?
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.
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?
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.
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?)
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.
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.
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.