Qu'est-ce que le statut de lecture TIC 1:57 dans iOS11 / Xcode 9?


158

Après la mise à jour vers Xcode 9, en utilisant Swift 3 et le simulateur iPhone X, ma console est pleine 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 y remédier? L'aide est très appréciée.

PS: Je préfère ne pas simplement le "faire taire" avec un Environment Variabledans le schéma de construction.


1
Copie

5
bien. J'ai aussi trouvé ce fil. mais c'est osx, vieux et pas vraiment répondu ...
David Seek

avez-vous encore trouvé une solution?
Khodour.F

2
ce qui est ennuyeux, ce n'est pas que cela se connecte à la console, mais cela semble aussi accrocher le fil principal
Hogdotmac

1
Oui. mais seulement en mode de débogage pour autant que je l'ai remarqué.
David Seek

Réponses:


182

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

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

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

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

Comme le sous-système de connexion d'E / S TCP n'a 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

MODIFIER / METTRE À JOUR:

Comme nous avons tous encore ces journaux ennuyeux, j'ai demandé au même spécialiste Apple à partir 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 également dans toutes mes applications depuis la mise à niveau vers 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 réaliser que cet ENOTCONN ne signifie pas nécessairement que quelque chose a mal tourné. Des 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, ma recommandation est que vous l'ignoriez.

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

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


30
Ce n'est pas spécifique à Swift. Je l'obtiens également avec Objectiv-C.
Victor Engel

8
Vous êtes vraiment allé au-delà des attentes pour obtenir cette réponse
G. LC

7
Votre solution ne semble pas avoir fonctionné, car elle est toujours présente dans XCode10.
Gennadii Tsypenko

2
nous devons trouver un moyen de nous en débarrasser, car l'impression des journaux affecte les performances de l'application pendant l'exécution, pour l'instant, nous pouvons espérer que pour les versions non #DEBUG, cela ne sera pas imprimé
Stoyan

6
ce serait bien d'avoir quelques paramètres, donc nous pourrions réellement "l'ignorer"
Zaporozhchenko Oleksandr

40

Voici comment TIC Read Status [11:0x0]: 1:57se décompose:

TIC se développe en «connexion TCP I / O», 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 vers l'objet TIC lui-même

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

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


d'accord. jusqu'ici tout va bien. est-ce quelque chose de mauvais ou juste une information? dois-je réparer quelque chose?
David Seek le

Je pense que cela a quelque chose à voir avec iOS11.0 et pourrait être corrigé dans les versions futures
0rt

8
Mais pourquoi cela se produit-il réellement? Et pourquoi a-t-il soudainement commencé avec iOS 11?
Lane Rettig

J'en reçois aussi une tonalité dans mon journal, mais tous mes appels réseau fonctionnent

Le même problème que dois-je faire avec cela?
Genevios

35

Remarque: comme ce que @David a mentionné dans le commentaire, c'est un moyen de masquer les avertissements, utilisez donc 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é, gardez-le désactivé 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 la variable à portée de main et basculer si nécessaire.

Utilisez OS_ACTIVITY_MODE = disablela variable d'environnement sous Arguments dans les schémas 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

entrez la description de l'image ici


13
J'ai aussi dit littéralement que je ne veux pas de son option ^^ Le simple fait de le faire taire ne résout pas le problème.
David Seek

23
Les gens doivent cesser de suggérer de désactiver toutes les instructions de journal. Les réponses comme celle-ci devraient être supprimées.
Claus Jørgensen

6

Le meilleur moyen que j'ai trouvé, concernant ce message de journal et quelques 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: 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")
    }
}

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

Notez qu'en appelant print sur la file d'attente principale, cela permet à votre enregistreur d'être utilisé à partir de threads sans mélanger votre console.

Prêt à être amélioré et peaufiné pour vos besoins :)


vérifiez "os_log". c'est la façon dont Apple recommande d'utiliser avec la journalisation avancée
user1105951

0

J'avais ce même problème où j'obtenais «}» en réponse à un service REST (GET).

En utilisant:

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

après avoir fait ma demande d'URL, et réinitialisé mon objet URLSession après avoir obtenu la réponse comme:

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

J'ai résolu mon problème.


1
Ne résoudra pas mon problème car cela se produit même si mon application ne fait que des appels à Firebase. Et je ne peux pas manipuler le cadre. Mais je transmettrai ceci à l'équipe de développement de Firebase. Peut-être qu'ils peuvent faire quelque chose à ce sujet.
David Seek

0

Nous parvenons à résoudre ce problème de journalisation en désactivant HTTP / 2 sur le serveur Web, dans notre cas, nous avons migré de l'ELB classique vers l'application ELB qui a ajouté la prise en charge de HTTP / 2 sur AWS et nous avons commencé à obtenir "TIC Read Status [11: 0x0 ]: 1:57 "sur la console XCode 10.1 / iOS 12. Cela ressemble à une solution temporaire jusqu'à ce qu'Apple corrige le problème avec HTTP / 2, le cas échéant. Cette solution peut ne pas fonctionner pour tout le monde, en particulier si vous utilisez des API tierces, mais elle vous donne des informations sur le problème.


4
Eh bien, cela fait un an et demi maintenant qu'Apple a introduit cette ... appelons-la ... fonctionnalité ... Je ne vois pas cela "corrigé" de si tôt.
David Seek

0

C'est une journalisation indiquant qu'une connexion TCP est perdue / fermée / non valide ou autre. Cela peut se produire si votre application a une connexion TCP en cours d'exécution et que l'application est mise en arrière-plan pendant un certain temps, ou si vous avez éteint l'écran de votre téléphone. Le système d'exploitation décide d'arrêter autant de ressources que possible pour réduire l'épuisement de la batterie. Si vous mettez l'application au premier plan, les connexions TCP que vous aviez auparavant ne fonctionneront plus. Vous devez recréer une nouvelle connexion TCP.

Si cela ne vous dérange pas, ignorez-le.

En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.