Anybody knows what 1:57 means? In previous macOses runs without error :-(
TIC Read Error 1:57
I'd like to know, too
There’s not enough context here to provide a meaningful response. Where are you seeing this message?
Share and Enjoy
—
Quinn “The Eskimo!”
Apple Developer Relations, Developer Technical Support, Core OS/Hardware
let myEmail = "eskimo" + "1" + "@apple.com"
Sorry for delay. The problem arises in MacosSierra. It's conventional http read from server retruning xml file. The message is in log with couple of other messages which follow:
default
17:48:25.189768 +0100
xSolMon
TIC TCP Conn Start [476:0x60800018dc30]
default
17:48:25.193585 +0100
xSolMon
TIC TCP Conn Event [476:0x60800018dc30]: 1 Err(0)
default
17:48:25.193618 +0100
xSolMon
TIC TCP Conn Connected [476:0x60800018dc30]: Err(0)
default
17:48:25.238365 +0100
xSolMon
TIC TCP Conn Event [476:0x60800018dc30]: 2 Err(0)
error
17:48:25.238419 +0100
xSolMon
TIC Read Error [476:0x60800018dc30]: 1:57
default
17:48:25.238474 +0100
xSolMon
TIC TCP Conn Cancel [476:0x60800018dc30]
default
17:48:25.238512 +0100
xSolMon
TIC TCP Conn Destroyed [476:0x60800018dc30]
TIC Read Error [476:0x60800018dc30]: 1:57
OK, here’s how this breaks down:
“TIC” expands to “TCP I/O connection”, which is a subsystem within CFNetwork that runs a TCP connection
“Read Error” is pretty self explanatory
“476” is a connection ID number within TIC; it’s not useful to you
“0x60800018dc30” is a pointer to the TIC object itself; again it’s not useful to you
“1” and “57” are the CFStreamError domain and code, respectively; a domain of 1 is
and, within that domain, 57 iskCFStreamErrorDomainPOSIX
ENOTCONN
In short, a TCP read has failed with
ENOTCONN
.
As the TCP I/O connection subsystem has no public API, you must necessarily be using it via some high-level wrapper (like NSURLSession). What API is that? Do you see the error manifest there? If so, what’s does that error look like?
Share and Enjoy
—
Quinn “The Eskimo!”
Apple Developer Relations, Developer Technical Support, Core OS/Hardware
let myEmail = "eskimo" + "1" + "@apple.com"
The problem is that even if I see error in system log, application works correctly (as it was in previous rel. of OSX), data is delivered and no error in debug. Thanks for explanation of this 1:57 code (TIC Read Error is definitelly selfexplanatory :-)). For app is used NSURLSessionDataTask
with completionHandler where is no error indication, errror == nil and no statusCode in NSHTTPURLResponse.
For me, these errors happen for Debug builds only during issuing `SKProductsRequest`:
SKProductsRequest *productsRequest = [[SKProductsRequest alloc] initWithProductIdentifiers:[NSSet setWithArray:skus]]; self.productsRequest = productsRequest; productsRequest.delegate = self; [productsRequest start];
And then, in Xcode debug console we do see this for couple minutes (like, hundreds of lines):
2017-11-08 13:04:25.876626+0700 app[5946:2030155] TIC Read Status [27:0x0]: 1:57
2017-11-08 13:04:25.876682+0700 app[5946:2030155] TIC Read Status [27:0x0]: 1:57
2017-11-08 13:04:25.878757+0700 app[5946:2030155] TIC Read Status [31:0x0]: 1:57
2017-11-08 13:04:25.878800+0700 app[5946:2030155] TIC Read Status [31:0x0]: 1:57
2017-11-08 13:04:25.881276+0700 app[5946:2030155] TIC Read Status [29:0x0]: 1:57
2017-11-08 13:04:25.881374+0700 app[5946:2030155] TIC Read Status [29:0x0]: 1:57
2017-11-08 13:04:25.914163+0700 app[5946:2030155] TIC Read Status [33:0x0]: 1:57
2017-11-08 13:04:25.914225+0700 app[5946:2030155] TIC Read Status [33:0x0]: 1:57
2017-11-08 13:04:25.914982+0700 app[5946:2030155] TIC Read Status [32:0x0]: 1:57
2017-11-08 13:04:25.915021+0700 app[5946:2030155] TIC Read Status [32:0x0]: 1:57
Then, apparently we have a call to SKProductsRequestDelegate.
If you’re using some high-level API and you see these log messages generally internally by that API, you can safely ignore them. These messages can be an interesting data point if you’re investigation an actual problem, but if everything is working otherwise then you don’t need to worry about them.
Share and Enjoy
—
Quinn “The Eskimo!”
Apple Developer Relations, Developer Technical Support, Core OS/Hardware
let myEmail = "eskimo" + "1" + "@apple.com"
We would be happy to ignore it, if it didn't cause us any issue. Unfortunatelly, it does.
These mesages are keeping posted for 2 minutes and only aftet that time we receive a response from SKProductsRequest. So, user waits for 2 minutes to see actual data. In other words, nothing is happening until these error messages appear in the Console.
Unfortunatelly, it does.
Bummer. Unfortunately this specific log point doesn’t help you much because the
ENOTCONN
error (see my 18 Jan post) just means that a TCP connection has closed. To learn more you need to dig into the logs generated by the high-level API you’re using.
In this case that means Store Kit. I don’t know anything about Store Kit debugging (sorry!) but you might try asking over in System Frameworks > In-App Purchase.
Share and Enjoy
—
Quinn “The Eskimo!”
Apple Developer Relations, Developer Technical Support, Core OS/Hardware
let myEmail = "eskimo" + "1" + "@apple.com"
@ekimo appreciate your response.
I can tell that not just network requests from the StoreKit cause this logs. It seems like any request to the network going this way. It makes me think about some "major malfunction" happening there. I was thinking about resetting network settings, but QAs reported the same issue on other devices as well.
And today, I also got this error:
TIC TCP Conn Failed [10:0x1c017a040]: 3:-9802 Err(-9802)
I can tell that not just network requests from the StoreKit cause this logs.
OK, in that case my recommendation would be:
Write a small test project that reproduces the problem using NSURLSession.
Run that on the affected device.
Dig into the issue using a CFNetwork diagnostics log (QA1887) and a packet trace (QA1176).
StoreKit is a complex beast so, if you can reproduce the problem outside of StoreKit, it’s best to do so.
And today, I also got this error:
-9802 is
errSSLFatalAlert
, which is raised by the TLS stack when things go wrong. There are two common cases for this:
When the TLS stack receives a fatal alert from the remote peer.
When ATS blocks a connection it simulates this.
Share and Enjoy
—
Quinn “The Eskimo!”
Apple Developer Relations, Developer Technical Support, Core OS/Hardware
let myEmail = "eskimo" + "1" + "@apple.com"
I was able to fix this on that particular test device by doing "Reset Content and Settings". Just resetting Network Settings didn't help, though.
I blame iOS, particulary that state it appeared to be before the reset...
@eskimo thank you for help.