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