A customer is reporting a connection failure with a strange profile: it apparently only fails for the very first URL request via CFNetwork since the app has launched.
The error code apparently being returned by CFNetwork is domain CFStreamErrorHTTP, but with error code -4, which does not correspond to any publicly defined error code for this domain.
In CFHTTPStream.h, the publicly defined error codes for CFStreamErrorHTTP end auspiciously at -3, strongly hinting that -4 may be an error code that Apple is using but which has not yet been publicly documented.
Any idea what's going on here? Has anybody else seen this error code and found rhyme or reason for it?
Probably not the final answer and this may have changed since they closed sourced CFNetwork, but I did find the following online which indicates that -4 is a connection lost error.
http://www.opensource.apple.com/source/CFNetwork/CFNetwork-129.9/HTTP/CFHTTPConnection.c
I guess you'll have to show some of the code that's failing, but a few questions spring to mind. First, can you trace this issue yourself, can you reproduce it? In particular, it would be interesting to see on which thread this happens, and what's the current runLoop mode. It could be indicative of a stream or connection that fails scheduling on the internal CF runloops.
Other than this (and it's a shame CFNetwork is no longer publicly updated), it could be a zillion things, but you'll need to log as much information as you can if you can't directly debug the failure (hint hint -- https://github.com/fpillet/NSLogger can help you remotely log the info from the client).
Finally, ask the question on Mac Dev Forums (or iOS Dev Forums if your code runs on iOS). Ping Quinn, He Knows It All. Once he can't publicly answer the question, open a DTS incident and send him the ticket #. He's the guy you want to look into your problem :-)
Related
I have a very tremendous issue in my app. App is using webrtc to create video connection between two people.
Currently the app it's in the test phase.
Everything is working fine on Chrome, but on Firefox there is a strange issue.
When the second Peer connects I receive this error:
Error adding ice candidate for pcInvalidStateError: setRemoteDescription needs to called before addIceCandidate
I know that the error message seems to be clear, but how it's possible that on Chrome this error does not exist?
I mean, maybe there is a bigger issue, not completely depending on this error message.
Do you have any ideas or solutions to this?
A part from WebRTC doc: (See Deprecated Exception section)
Deprecated exceptions
When using the deprecated callback-based version of
setRemoteDescription(), the following exceptions may occur:
InvalidStateError The connection's signalingState is "closed",
indicating that the connection is not currently open, so negotiation
cannot take place.
You should check you are not using deprecated callback version of this function. Also you should keep an eye on signalingState of the peer connection.
Hope it helps!
I'm tinkering with connection to our work Exchange thing from Linux and trying to understand what is happening with the autodiscover process.
I start with
curl -u 'xxxx' https://outlook.office365.com/EWS/Exchange.asmx
and get back a page that I've created a service and says to point at
https://am3pr05mb0677.eurprd05.prod.outlook.com:444/EWS/Services.wsdl
but dns lookup (dig) on am3pr05mb0677.eurprd05.prod.outlook.com fails, as does digging for eurprd05.prod.outlook.com and prod.outlook.com. All I get back is a SOA record.
Basically, WTH is going on? I've googled my fingers off and found lots of references to eurprd05.prod.outlook.com but they all seem to be from people who are not having any trouble resolving the name. Why me?!
Ultimately, this is aiming at command line room booking function for work, but that's a long way off at the moment!
I was testing my app and I noticed this error message popping up from the PFQueryCollectionViewController:
2015-07-06 21:40:58.445 Noms[320:29335] [Error]: The Internet connection appears to be offline. (Code: 100, Version: 1.7.5)
2015-07-06 21:40:58.446 Noms[320:29335] [Error]: Network connection failed. Making attempt 2 after sleeping for 1.604623 seconds.
This was expected, since my phone was not connected to the internet. However, I want to detect this error and handle it myself, rather having the endless loading scroll on the screen. Looking at the documentation didn't yield any variables that I thought could be useful.
Does anyone know how I might receive this callback so I can handle them?
Parse provides a "cancel" method on all PFQueries, including the one in PFQueryTableViewController. In theory, you could cancel your query after a timeout of your choosing. Unfortunately, many developers are reporting a bug in that method that prevents it from working.
My best recommendation recommendation is to check for internet connection before firing your query. Apple's Reachability project is a great tool for this.
Without going into too much detail (I am looking for debugging techniques here), I would like to understand how to better debug Xlib failed requests. In particular dealing with the glx extension. The occurrence of the bug I am fighting is in a complex place within my application and trying to pull it apart to provide a small sample here is not possible.
With that said the failed request I am seeing is
x10: fatal 10 error 11 (Resource temporarily unavailable) on X server ":0.0"
after 46 requests (46 know processed) with 0 event remaining.
X Error of failed request: BadAccess (attempt to access private resource denied)
Major opcode of failed request: 135 (GLX)
Minor opcode of failed request: 5 (XGLMakeCurrent)
Serial number of failed request: 46
Current serial number in output stream: 46
I can see where the problem is being caused by stepping through with the debugger. However, I can't fully discern why it is happening.
The clue where to look is in the name of the extension and the name of the request itself. Unfortunately in this case because of your use of Xgl this isn't so helpful. But you can check what the request really is by checking out the protocol documentation like this one for glproto. From that you can see that the request is really glxMakeCurrent. Then you just need to find the documentation or code for that request.
The GLX specification says glxMakeCurrent will give BadAccess if "the context is current to some other thread".
Now, your error is about XGLMakeCurrent which is an implementation detail of Xgl . But from reading the implementation of this function it passes through to the the underlying GLX implementation.
To fix your problem I suggest you try and identify if that context is being used in another thread.
For debugging you want to turn on synchronous requests, this slows down your code but will make every X request wait until the server processes it before continuing and immediately return an error. You can turn it on with
XSynchronize(display, True);
Now you will get the X error at the routine that caused the issue and can use standard debugging tools from there.
We have a fairly standard client/server application built using MS RPC. Both client and server are implemented in C++. The client establishes a session to the server, then makes repeated calls to it over a period of time before finally closing the session.
Periodically, however, especially under heavy load conditions, we are seeing an RPC exception show up with code 1754: RPC_S_NOTHING_TO_EXPORT.
It appears that this happens in the middle of a session. The user is logged on for a while, making successful calls, then one of the calls inexplicably returns this error. As far as we can tell, the server receives no indication that anything went wrong - and it definitely doesn't see the call the client made.
The error code appears to have permanent implications, as well. Having the client retry the connection doesn't work, either. However, if the user has multiple user sessions active simultaneously between the same client and server, the other connections are unaffected.
In essence, I have two questions:
Does anyone know what RPC_S_NOTHING_TO_EXPORT means? The MSDN documentation simply says: "No interfaces have been exported." ... Huh? The session was working fine for numerous instances of the same call up until this point...
Does anyone have any ideas as to how to identify the real problem? Note: Capturing network traffic is something we would rather avoid, if possible, as the problem is sporadic enough that we would likely go through multiple gigabytes of traffic before running into an occurrence.
Capturing network traffic would be one of the best ways to tackle this issue. If you can't do that, could you dump the client process and debug with WinDBG or Visual Studio? Perhaps compare a dump when operating normally versus in the error state?