What is TIC Read Status 1:57 in iOS11/Xcode 9?

59,700

Solution 1

Apple staff gave the following answer:

TIC expands to “TCP I/O connection”, which is a subsystem within CFNetwork that runs a TCP connection

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).

source: https://forums.developer.apple.com/thread/66058

EDIT/UPDATE:

Since we are all still having these annoying logs, I asked to the same Apple specialist from the above link about our situation, which is now specific for Xcode 9 and Swift 4. Here it is:

A lot of people are complaining about these logs, which I am having as well in all my apps since I upgraded to Xcode 9 / iOS 11.

2017-10-24 15:26:49.120556-0300 MyApp[1092:314222] TIC Read Status [55:0x0]: 1:57  
2017-10-24 15:26:49.120668-0300 MyApp[1092:314222] TIC Read Status [55:0x0]: 1:57  
2017-10-24 15:26:49.626199-0300 MyApp[1092:314617] TIC Read Status [56:0x0]: 1:57

His answer:

It’s important to realise that this ENOTCONN does not necessarily mean that anything has gone wrong. Closed TCP connections are expected in all versions of HTTP. So, unless there’s some other symptom associated with this error, my recommendation is that you ignore it.

source: https://forums.developer.apple.com/message/272678#272678

SOLUTION: Just wait for newer versions/updates of Xcode 9.

Solution 2

Here is how TIC Read Status [11:0x0]: 1:57 breaks down:

TIC expands to “TCP I/O connection”, which is a subsystem within CFNetwork that runs a TCP connection

11 is a connection ID number within TIC

0x0 is a pointer to the TIC object itself

1 and 57 are the CFStreamError domain and code, respectively; a domain of 1 is kCFStreamErrorDomainPOSIX and, within that domain, 57 is ENOTCONN

Source: https://forums.developer.apple.com/thread/66058

Solution 3

Note: Like what @David mentioned in the comment, it's a way to hide the warnings, so use this launch argument to avoid getting many repetitive messages and have a clean console. Once done debugging, keep it disabled as console doesn't provide useful information when it's enabled. For example libc++abi.dylib: terminating with uncaught exception of type NSException.

For people who are wondering how to silence the warning and until a better fix is available you may keep following variable handy and toggle as needed.

Use OS_ACTIVITY_MODE = disable environment variable under Arguments in the product schemes to avoid console getting flooded with such warnings.

Note B: Enable it to see the effect.

Source: https://medium.com/@adinugroho/disable-os-logging-in-xcode-8-ec6d38502532

enter image description here

Solution 4

The best way I found, concerning this log message and some others ( like NSURLSession errors that are not necessarily errors ) is to have my own log functions.

class Logger {
    static var project: String = "MyProject"

    static func log(_ string: String, label: String = "") {
        DispatchQueue.main.async {
            print("[\(Logger.project)] \(label) : \(string)")
        }
    }

    static func info(_ string: String) {
        Logger.log(string)
    }

    static func warning(_ string: String) {
        Logger.log(string, label: "WARNING")
    }

    static func error(_ string: String) {
        Logger.log(string, label: "ERROR")
    }
}

Then I simply type [MyProject] in the console pane bottom-right filter, and that's it.

Note that by calling print on the main queue, it allows your logger to be used from threads without mixing up your console.

Ready to be improved and tweaked for your needs :)

Share:
59,700

Related videos on Youtube

David Seek
Author by

David Seek

https://www.linkedin.com/in/david-seek/

Updated on July 08, 2022

Comments

  • David Seek
    David Seek almost 2 years

    After updating to Xcode 9, using Swift 3 and the iPhone X simulator, my console is full of:

    TIC Read Status [11:0x0]: 1:57
    TIC Read Status [11:0x0]: 1:57
    TIC Read Status [11:0x0]: 1:57
    ...
    

    What is that and how do I fix it? Help is very appreciated.

    PS: I prefer not to just "silence" it with an Environment Variable in the build scheme.

    • timgcarlson
      timgcarlson almost 7 years
    • David Seek
      David Seek almost 7 years
      well. i have found this thread as well. but it's osx, old and not really answered...
    • Kodr.F
      Kodr.F over 6 years
      did u find a solution yet ?
    • David Seek
      David Seek over 6 years
      @Jack. No not at all.
    • Hogdotmac
      Hogdotmac over 6 years
      the annoying thing is not that this logs into console, but it also seems to hang the main thread
    • David Seek
      David Seek over 6 years
      yes it does. but only in debugging mode as far as i noticed.
  • David Seek
    David Seek almost 7 years
    okay. so far so good. is that something bad or just an information? do i need to fix anything?
  • 0rt
    0rt almost 7 years
    I believe it has something to do with iOS11.0 and might be fixed in future releases
  • Lane Rettig
    Lane Rettig over 6 years
    But why is it actually happening? And why did it suddenly start with iOS 11?
  • Admin
    Admin over 6 years
    I am getting a tones of them too in my log but all my network calls are working fine :L
  • David Seek
    David Seek over 6 years
    Also I have literally said, that I do not want his option ^^ Just silencing it doesn't get rid of the problem.
  • Genevios
    Genevios over 6 years
    The same problem what i must do with this?
  • Kingalione
    Kingalione over 6 years
    Same problem here. My app works fine but still getting this error
  • rgoncalv
    rgoncalv over 6 years
    @LaneRettig, check my answer below.
  • Kodr.F
    Kodr.F over 6 years
    Same issue here with firebase , any solution ?
  • Victor Engel
    Victor Engel over 6 years
    This is not specific to Swift. I am getting it with Objectiv-C as well.
  • David Seek
    David Seek about 6 years
    Will not solve my issue as this even happens if all my App does is calls to Firebase. And I can't manipulate the framework. But I will forward this to Firebase dev team. Maybe they can do something about it.
  • G. LC
    G. LC almost 6 years
    You really went above and beyond to get this answer
  • Gennadii Tsypenko
    Gennadii Tsypenko over 5 years
    Your solution seems not to have worked, since it's still there in XCode10.
  • Stoyan
    Stoyan over 5 years
    we have to find a way to get rid of this, because log printing affects the app performance during runtime, for now we can hope, that for non #DEBUG builds this will not get printed
  • Søren Pedersen
    Søren Pedersen over 5 years
    People need to stop suggesting disabling all log statements. Answers like this should be deleted.
  • Zaporozhchenko Oleksandr
    Zaporozhchenko Oleksandr over 5 years
    would be nice have some settings, so we could actually "ignore it"
  • David Seek
    David Seek over 5 years
    Well it has been 1.5 years now since Apple introduced this... let's call it... feature... I don't see this being "fixed" any time soon.
  • AverageHelper
    AverageHelper about 5 years
    Since the idea seems to be to ignore it, I'm gonna leave this here. Basically, you can ignore all the odd system console output with an environment variable: OS_ACTIVITY_MODE = disable. Link: forums.developer.apple.com/thread/51196#thread-message-18268‌​4
  • user1105951
    user1105951 almost 5 years
    check "os_log" . this is way apple recommend to use with advanced logging