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.
This failure seems to be occurring for the majority, if not all of the test case sources for TestNTLM. It appears that a web request timeout could be causing this issue, I'm not certain if the wifi could be the culprit, as Martin has not seen failures similar to the one below:
GOT WEB EXCEPTION: System.Net.WebException: The request timed out
at System.Net.HttpWebRequest.EndGetResponse (IAsyncResult asyncResult) [0x00000] in <filename unknown>:0
at System.Net.HttpWebRequest.GetResponse () [0x00000] in <filename unknown>:0
at Xamarin.WebTests.Runners.TestRunner.Run (Xamarin.WebTests.Handlers.Handler handler, HttpStatusCode expectedStatus, Boolean expectException) [0x00000] in <filename unknown>:0
[AuthenticationHandler: AuthenticationHandler: Content-Length]: RUN DONE
[FAIL] TestNTLM([PostHandler: Content-Length]) : System.NullReferenceException : Object reference not set to an instance of an object
Partial test output:
XA 4.12-series / 3c3c2f0f
Nexus 5 v4.4 (ART)
Here's the full test output, it took about 10 minutes to run.
Tests run: 439, Passed: 434, Failed: 5, Skipped: 0, Inconclusive: 0
This should be fixed now with my new improved IPAddress detection.
You should see either 440 tests pass when you have wifi or 142 pass and 1 failure on aircraft mode.
I also changed all the non-proxy tests back to using the loopback interface.
We previously listened on some port 999x on the wifi interface (or whatever IPAddress that localhost lookup returned), the timeout could be due to some networking issues / wifi being down, etc..
The proxy tests need a non-loopback interface because the brain-dead web stack would ignore all web proxies when using the loopback interface.
Hey Martin I'm still seeing these failures on web-tests / 564a82db. Do we need to bump monodroid again to bring in any of these fixes or are they only changes in the web-tests repo itself?
*** This bug has been marked as a duplicate of bug 20625 ***