web-dev-qa-db-fra.com

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

Après la mise à jour vers Xcode 9, avec 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 puis-je le réparer? L'aide est très appréciée. 

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

131
David Seek

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

TIC se développe en «connexion TCP I/O», qui est un sous-système au sein 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.

Le sous-système de connexion d'E/S TCP ne disposant pas d'une 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:

Puisque nous avons tous encore ces journaux ennuyeux, j’ai interrogé le même spécialiste Apple sur le lien ci-dessus à propos de notre situation, qui est maintenant spécifique à Xcode 9 et Swift 4. Voici ce qui suit:

Beaucoup de gens se plaignent de ces journaux, ce que je rencontre é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 tout va mal. Des connexions TCP fermées sont attendues dans toutes les versions de HTTP. Par conséquent, à moins d’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 dernières versions/mises à jour de Xcode 9.

159
rgoncalv

Voici comment TIC Read Status [11:0x0]: 1:57 se 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 sur l'objet 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

39
0rt

Remarque: comme ce que @ David a mentionné dans le commentaire, il s'agit d'un moyen de masquer les avertissements. Utilisez donc cet argument de lancement pour éviter de recevoir de nombreux messages répétitifs et utilisez une console vierge. Une fois le débogage terminé, laissez-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 lettre et à alterner selon les besoins.

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

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

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

 enter image description here

29
lal

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 volet de la console, et c'est tout.

Notez qu'en appelant print dans la file principale, vous pouvez utiliser votre consignateur à partir de threads sans mélanger votre console.

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

3
Moose

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 objet URLSession après avoir obtenu la réponse sous la forme:

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

Résolu mon problème.

0
Anuj Nigam

Nous avons réussi à résoudre ce problème de journalisation en désactivant HTTP/2 sur le serveur Web. Dans notre cas, nous avons migré d'ELB classique vers une application ELB qui ajoutait une 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 que Apple résolve 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 un aperçu du problème.

0
Starkode