Qu’est-ce que TIC Read Status 1:57 dans iOS11 / Xcode 9?

Après la mise à jour vers Xcode 9, en utilisant Swift 3 et le simulateur iPhone X, ma console est remplie de:

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

Qu’est-ce que c’est et comment puis-je le réparer? L’aide est très appréciée.

PS: Je préfère ne pas le “faire taire” avec une Environment Variable dans le schéma de construction.

Le personnel d’Apple a donné la réponse suivante:

TIC développe en «connexion TCP E / S», qui est un sous-système de CFNetwork qui exécute une connexion TCP

1 et 57 sont respectivement le domaine et le code CFStreamError; un domaine de 1 est kCFStreamErrorDomainPOSIX et, dans ce domaine, 57 est ENOTCONN

En bref, une lecture TCP a échoué avec ENOTCONN.

Comme le sous-système de connexion TCP I / O ne possède pas d’API publique, vous devez nécessairement l’utiliser via un wrapper de haut niveau (comme NSURLSession).

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

EDIT / UPDATE:

Comme nous avons toujours ces journaux ennuyeux, j’ai demandé au même spécialiste Apple du lien ci-dessus à propos de notre situation , qui est maintenant spécifique pour Xcode 9 et Swift 4. La voici:

Beaucoup de gens se plaignent de ces journaux, que j’ai aussi dans toutes mes applications depuis que je suis passé à 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 

Sa réponse:

Il est important de comprendre que cette ENOTCONN ne signifie pas nécessairement que quelque chose a mal tourné. Les connexions TCP fermées sont attendues dans toutes les versions de HTTP. Donc, à moins qu’il y ait un autre symptôme associé à cette erreur, je vous recommande de l’ignorer.

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

SOLUTION: attendez les nouvelles versions / mises à jour de Xcode 9.

Voici comment TIC Read Status [11:0x0]: 1:57 tombe en panne:

TIC développe en «connexion TCP E / S», qui est un sous-système de CFNetwork qui exécute une connexion TCP

11 est un numéro d’identification de connexion dans TIC

0x0 est un pointeur sur l’object TIC lui-même

1 et 57 sont respectivement le domaine et le code CFStreamError; un domaine de 1 est kCFStreamErrorDomainPOSIX et, dans ce domaine, 57 est ENOTCONN

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

Note: Comme ce que @David a mentionné dans le commentaire, c’est un moyen de masquer les avertissements, alors utilisez cet argument de lancement pour éviter de recevoir de nombreux messages répétitifs et avoir une console propre. Une fois le débogage terminé, désactivez-le car la console ne fournit pas d’informations utiles lorsqu’elle est activée. Par exemple, libc++abi.dylib: terminating with uncaught exception of type NSException .

Pour les personnes qui se demandent comment faire taire l’avertissement et jusqu’à ce qu’un meilleur correctif soit disponible, vous pouvez continuer à suivre les variables à scope de main et à basculer si nécessaire.

Utilisez OS_ACTIVITY_MODE = disable la variable d’environnement sous Arguments dans les modèles de produit pour éviter que la console ne soit inondée de tels avertissements.

Remarque B: Activez-le pour voir l’effet.

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

entrer la description de l'image ici

Le meilleur moyen que j’ai trouvé concernant ce message de journal et d’autres (comme les erreurs NSURLSession qui ne sont pas nécessairement des erreurs) est d’avoir mes propres fonctions de journal.

 class Logger { static var project: Ssortingng = "MyProject" static func log(_ ssortingng: Ssortingng, label: Ssortingng = "") { DispatchQueue.main.async { print("[\(Logger.project)] \(label) : \(ssortingng)") } } static func info(_ ssortingng: Ssortingng) { Logger.log(ssortingng) } static func warning(_ ssortingng: Ssortingng) { Logger.log(ssortingng, label: "WARNING") } static func error(_ ssortingng: Ssortingng) { Logger.log(ssortingng, label: "ERROR") } } 

Ensuite, je tape simplement [MyProject] dans le filtre en bas à droite du volet de la console, et c’est tout.

Notez qu’en appelant print sur la queue principale, cela permet d’utiliser votre enregistreur à partir des threads sans mélanger votre console.

Prêt à être amélioré et adapté à vos besoins 🙂

J’avais ce même problème où je recevais ‘}’ en réponse à un service REST (GET).

En utilisant:

 URLCache.shared.removeCachedResponse(for: request as URLRequest) 

après avoir effectué ma demande d’URL et réinitialisé mon object URLSession après avoir reçu la réponse en tant que:

 session.reset(completionHandler: { // print(\(data)) }) 

Résolu mon problème.