Was ist der TIC-Lesestatus 1:57 in iOS11 / Xcode 9?

158

Nach dem Update auf Xcode 9 mit Swift 3 und dem iPhone X-Simulator ist meine Konsole voll mit:

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

Was ist das und wie behebe ich es? Hilfe wird sehr geschätzt.

PS: Ich ziehe es vor, es nicht einfach mit einem Environment Variableim Build-Schema "zum Schweigen zu bringen" .

David Seek
quelle
1
Mögliches Duplikat von stackoverflow.com/questions/40226104/…
timgcarlson
5
Gut. Ich habe diesen Thread auch gefunden. aber es ist osx, alt und nicht wirklich beantwortet ...
David Seek
Hast du schon eine Lösung gefunden?
Khodour.F
2
Das nervige ist nicht, dass sich dies in der Konsole anmeldet, aber es scheint auch den Haupt-Thread zu hängen
Hogdotmac
1
ja tut es. aber nur im Debugging-Modus, soweit ich es bemerkt habe.
David Seek

Antworten:

182

Apple-Mitarbeiter gaben die folgende Antwort:

TIC wird zu "TCP-E / A-Verbindung" erweitert, einem Subsystem innerhalb von CFNetwork, das eine TCP-Verbindung ausführt

1und 57sind die CFStreamError-Domäne bzw. der Code; Eine Domäne von 1 ist kCFStreamErrorDomainPOSIX und innerhalb dieser Domäne57 ist ENOTCONN

Kurz gesagt, ein TCP-Lesevorgang ist mit ENOTCONN fehlgeschlagen.

Da das TCP-E / A-Verbindungssubsystem keine öffentliche API hat, müssen Sie es unbedingt über einen High-Level-Wrapper (wie NSURLSession) verwenden.

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

EDIT / UPDATE:

Da wir alle immer noch diese nervigen Protokolle haben, habe ich denselben Apple-Spezialisten über den obigen Link nach unserer Situation gefragt , die jetzt spezifisch für Xcode 9 und Swift 4 ist. Hier ist sie:

Viele Leute beschweren sich über diese Protokolle, die ich seit dem Upgrade auf Xcode 9 / iOS 11 auch in all meinen Apps habe.

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

Seine Antwort:

Es ist wichtig zu wissen, dass diese ENOTCONN nicht unbedingt bedeutet, dass etwas schief gelaufen ist. Geschlossene TCP-Verbindungen werden in allen HTTP-Versionen erwartet. Sofern mit diesem Fehler kein anderes Symptom verbunden ist, empfehle ich, ihn zu ignorieren.

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

LÖSUNG: Warten Sie einfach auf neuere Versionen / Updates von Xcode 9.

rgoncalv
quelle
30
Dies ist nicht spezifisch für Swift. Ich bekomme es auch mit Objectiv-C.
Victor Engel
8
Sie haben wirklich
G. LC
7
Ihre Lösung scheint nicht funktioniert zu haben, da sie in XCode10 noch vorhanden ist.
Gennadii Tsypenko
2
Wir müssen einen Weg finden, dies zu beseitigen, da das Drucken von Protokollen die App-Leistung zur Laufzeit beeinflusst. Im Moment können wir hoffen, dass dies für Nicht-#DEBUG-Builds nicht gedruckt wird
Stoyan,
6
wäre schön, einige Einstellungen zu haben, so könnten wir es tatsächlich "ignorieren"
Zaporozhchenko Oleksandr
40

So TIC Read Status [11:0x0]: 1:57bricht das zusammen:

TIC wird zu "TCP-E / A-Verbindung" erweitert, einem Subsystem innerhalb von CFNetwork, das eine TCP-Verbindung ausführt

11 ist eine Verbindungs-ID-Nummer innerhalb von TIC

0x0 ist ein Zeiger auf das TIC-Objekt selbst

1 und 57 sind die CFStreamError-Domäne bzw. der Code; Eine Domäne von 1 ist kCFStreamErrorDomainPOSIX und innerhalb dieser Domäne ist 57 ENOTCONN

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

0rt
quelle
in Ordnung. So weit, ist es gut. Ist das etwas Schlechtes oder nur eine Information? Muss ich etwas reparieren?
David Seek
Ich glaube, es hat etwas mit iOS11.0 zu tun und könnte in zukünftigen Versionen
behoben werden
8
Aber warum passiert es eigentlich? Und warum hat es plötzlich mit iOS 11 angefangen?
Lane Rettig
Ich bekomme auch einen Ton von ihnen in meinem Protokoll, aber alle meine Netzwerkanrufe funktionieren
Das gleiche Problem, was muss ich damit machen?
Genevios
35

Hinweis: Wie bei @David im Kommentar erwähnt, können die Warnungen auf diese Weise ausgeblendet werden. Verwenden Sie dieses Startargument, um zu vermeiden, dass sich viele Nachrichten wiederholen, und verfügen Sie über eine saubere Konsole. Lassen Sie das Debugging nach dem Debuggen deaktiviert, da die Konsole bei Aktivierung keine nützlichen Informationen liefert. Zum Beispiel libc++abi.dylib: terminating with uncaught exception of type NSException.

Für Leute, die sich fragen, wie sie die Warnung zum Schweigen bringen können und bis eine bessere Lösung verfügbar ist, können Sie die Variable weiterhin zur Hand haben und nach Bedarf umschalten.

Verwenden OS_ACTIVITY_MODE = disable Umgebungsvariable unter Argumente in den Produktschemata, um zu vermeiden, dass die Konsole mit solchen Warnungen überflutet wird.

Hinweis B: Aktivieren Sie diese Option, um den Effekt anzuzeigen.

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

Geben Sie hier die Bildbeschreibung ein

lal
quelle
13
Auch ich habe buchstäblich gesagt, dass ich seine Option nicht will ^^ Nur das Schweigen zu bringen, wird das Problem nicht los.
David Seek
23
Die Benutzer müssen aufhören, alle Protokollanweisungen zu deaktivieren. Antworten wie diese sollten gelöscht werden.
Claus Jørgensen
6

Der beste Weg, den ich in Bezug auf diese Protokollnachricht und einige andere (wie NSURLSession-Fehler, die nicht unbedingt Fehler sind) gefunden habe, besteht darin, meine eigenen Protokollfunktionen zu haben.

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")
    }
}

Dann tippe ich einfach [MyProject] in den Filter unten rechts im Konsolenbereich und fertig .

Beachten Sie, dass durch Aufrufen von print in der Hauptwarteschlange Ihr Logger von Threads aus verwendet werden kann, ohne die Konsole zu verwechseln.

Bereit, verbessert und an Ihre Bedürfnisse angepasst zu werden :)

Elch
quelle
Überprüfen Sie "os_log". Auf diese Weise empfiehlt Apple die Verwendung mit erweiterter Protokollierung
user1105951
0

Ich hatte das gleiche Problem, bei dem ich als Antwort auf einen REST (GET) -Dienst '}' erhielt.

Verwenden von:

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

Nachdem Sie meine URL-Anfrage gestellt und mein URLSession-Objekt zurückgesetzt haben, nachdem Sie die Antwort erhalten haben:

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

Mein Problem gelöst.

Anuj Nigam
quelle
1
Wird mein Problem nicht lösen, da dies sogar passiert, wenn meine App nur Firebase aufruft. Und ich kann das Framework nicht manipulieren. Aber ich werde dies an das Firebase-Entwicklerteam weiterleiten. Vielleicht können sie etwas dagegen tun.
David Seek
0

Wir haben es geschafft, dieses Protokollierungsproblem durch Deaktivieren von HTTP / 2 auf dem Webserver zu lösen. In unserem Fall haben wir von der klassischen ELB zur Anwendungs-ELB migriert, die HTTP / 2 unter AWS unterstützt, und haben den Status "TIC-Lesestatus [11: 0x0" erhalten ]: 1:57 "auf der XCode 10.1 / iOS 12-Konsole. Dies scheint eine vorübergehende Lösung zu sein, bis Apple das Problem mit HTTP / 2 behoben hat, falls vorhanden. Diese Lösung funktioniert möglicherweise nicht für alle, insbesondere wenn Sie APIs von Drittanbietern verwenden, gibt Ihnen jedoch einige Einblicke in das Problem.

Starkode
quelle
4
Nun, es ist nun 1,5 Jahre her, seit Apple diese Funktion eingeführt hat ... nennen wir es ... Ich sehe nicht, dass dies bald "behoben" wird.
David Seek
0

Es ist eine Protokollierung, die angibt, dass eine TCP-Verbindung verloren / geschlossen / nicht_valid oder was auch immer ist. Dies kann passieren, wenn Ihre App eine laufende TCP-Verbindung hat und die App für einige Zeit in den Hintergrund gestellt wird oder Sie den Bildschirm Ihres Telefons ausgeschaltet haben. Das Betriebssystem beschließt, so viele Ressourcen wie möglich zu stoppen, um den Batterieverbrauch zu verringern. Wenn Sie die App in den Vordergrund stellen, funktionieren die TCP-Verbindungen, die Sie zuvor hatten, nicht mehr. Sie müssen eine neue TCP-Verbindung neu erstellen.

Wenn es Sie nicht stört, ignorieren Sie es einfach.

AndaluZ
quelle