TIC Read Error 1:57

Anybody knows what 1:57 means? In previous macOses runs without error :-(

Replies

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

    kCFStreamErrorDomainPOSIX
    and, within that domain, 57 is
    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:

  1. Write a small test project that reproduces the problem using NSURLSession.

  2. Run that on the affected device.

  3. Dig into the issue using a CFNetwork diagnostics log (QA1887) and a packet trace (QA1176).

StoreKit is a complex ***** 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.