Apa itu Status Baca TIC 1:57 di iOS11 / Xcode 9?


158

Setelah memperbarui ke Xcode 9, menggunakan Swift 3 dan simulator iPhone X, konsol saya penuh dengan:

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

Apa itu dan bagaimana cara memperbaikinya? Bantuan sangat dihargai.

PS: Saya lebih suka untuk tidak "diam" saja dengan Environment Variableskema build.



5
baik. saya telah menemukan utas ini juga. tapi ini OSX, tua dan tidak benar-benar dijawab ...
David Seek

apakah kamu sudah menemukan solusinya?
Khodour.F

2
hal yang menjengkelkan bukanlah bahwa ini masuk ke konsol, tetapi tampaknya juga menggantung utas utama
Hogdotmac

1
ya benar. tetapi hanya dalam mode debugging sejauh yang saya perhatikan.
David Seek

Jawaban:


182

Staf Apple memberikan jawaban berikut:

TIC memperluas ke "koneksi TCP I / O", yang merupakan subsistem dalam CFNetwork yang menjalankan koneksi TCP

1dan 57masing-masing adalah domain dan kode CFStreamError; domain 1 adalah kCFStreamErrorDomainPOSIX dan, dalam domain itu, 57adalah ENOTCONN

Singkatnya, pembacaan TCP gagal dengan ENOTCONN.

Karena subsistem koneksi I / O TCP tidak memiliki API publik, Anda harus menggunakannya melalui beberapa pembungkus tingkat tinggi (seperti NSURLSession).

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

EDIT / PEMBARUAN:

Karena kita semua masih memiliki log yang menjengkelkan ini, saya bertanya kepada spesialis Apple yang sama dari tautan di atas tentang situasi kita , yang sekarang khusus untuk Xcode 9 dan Swift 4. Ini dia:

Banyak orang mengeluh tentang log ini, yang saya miliki juga di semua aplikasi saya sejak saya memutakhirkan ke 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

Jawabannya:

Sangat penting untuk menyadari bahwa ENOTCONN ini tidak selalu berarti bahwa ada yang salah. Koneksi TCP tertutup diharapkan di semua versi HTTP. Jadi, kecuali ada gejala lain yang terkait dengan kesalahan ini, rekomendasi saya adalah Anda mengabaikannya.

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

SOLUSI: Tunggu saja versi / pembaruan Xcode 9 yang lebih baru.


30
Ini tidak spesifik untuk Swift. Saya mendapatkannya dengan Objectiv-C juga.
Victor Engel

8
Anda benar-benar pergi di atas dan di luar untuk mendapatkan jawaban ini
G. LC

7
Solusi Anda tampaknya tidak berhasil, karena masih ada di XCode10.
Gennadii Tsypenko

2
kita harus menemukan cara untuk menghilangkan ini, karena pencetakan log mempengaruhi kinerja aplikasi selama runtime, untuk sekarang kita dapat berharap, bahwa untuk build non #DEBUG ini tidak akan dicetak
Stoyan

6
akan lebih baik memiliki beberapa pengaturan, sehingga kita benar-benar bisa "mengabaikannya"
Zaporozhchenko Oleksandr

40

Inilah cara TIC Read Status [11:0x0]: 1:57memecah:

TIC memperluas ke "koneksi TCP I / O", yang merupakan subsistem dalam CFNetwork yang menjalankan koneksi TCP

11 adalah nomor ID koneksi dalam TIC

0x0 adalah pointer ke objek TIC itu sendiri

1dan 57masing-masing adalah domain dan kode CFStreamError; domain 1 adalah kCFStreamErrorDomainPOSIX dan, dalam domain itu, 57 adalah ENOTCONN

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


baik. sejauh ini baik. apakah itu sesuatu yang buruk atau hanya informasi? apakah saya perlu memperbaiki sesuatu?
David Seek

Saya percaya ini ada hubungannya dengan iOS11.0 dan mungkin diperbaiki dalam rilis mendatang
0rt

8
Tetapi mengapa itu benar-benar terjadi? Dan mengapa itu tiba-tiba dimulai dengan iOS 11?
Lane Rettig

Saya mendapatkan nada mereka juga di log saya, tetapi semua panggilan jaringan saya berfungsi dengan baik: L

Masalah yang sama apa yang harus saya lakukan dengan ini?
Genevios

35

Catatan: Seperti apa yang @David sebutkan dalam komentar, ini adalah cara untuk menyembunyikan peringatan, jadi gunakan argumen peluncuran ini untuk menghindari mendapatkan banyak pesan berulang dan memiliki konsol yang bersih. Setelah selesai debugging, tetap dinonaktifkan karena konsol tidak memberikan informasi yang berguna ketika diaktifkan. Sebagai contoh libc++abi.dylib: terminating with uncaught exception of type NSException.

Untuk orang-orang yang bertanya-tanya bagaimana cara membungkam peringatan dan sampai perbaikan yang lebih baik tersedia, Anda dapat tetap mengikuti variabel berguna dan beralih sesuai kebutuhan.

Gunakan OS_ACTIVITY_MODE = disablevariabel lingkungan di bawah Argumen dalam skema produk untuk menghindari konsol kebanjiran peringatan tersebut.

Catatan B: Aktifkan untuk melihat efeknya.

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

masukkan deskripsi gambar di sini


13
Juga saya benar-benar mengatakan, bahwa saya tidak menginginkan pilihannya ^^ Hanya membungkamnya tidak menghilangkan masalah.
David Seek

23
Orang-orang perlu berhenti menyarankan untuk menonaktifkan semua pernyataan log. Jawaban seperti ini harus dihapus.
Claus Jørgensen

6

Cara terbaik yang saya temukan, mengenai pesan log ini dan beberapa lainnya (seperti kesalahan NSURLSession yang belum tentu kesalahan) adalah memiliki fungsi log saya sendiri.

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

Kemudian saya cukup mengetik [MyProject] di filter kanan bawah panel konsol, dan hanya itu.

Perhatikan bahwa dengan memanggil print pada antrian utama, ini memungkinkan logger Anda untuk digunakan dari utas tanpa mencampur konsol Anda.

Siap ditingkatkan dan disesuaikan untuk kebutuhan Anda :)


periksa "os_log". ini adalah cara yang direkomendasikan apel untuk digunakan dengan pencatatan tingkat lanjut
user1105951

0

Saya mengalami masalah yang sama di mana saya mendapatkan '}' sebagai tanggapan terhadap layanan REST (GET).

Menggunakan:

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

setelah membuat permintaan URL saya, dan mengatur ulang objek URLSession saya setelah mendapatkan respons sebagai:

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

Memecahkan masalah saya.


1
Tidak akan menyelesaikan masalah saya karena ini bahkan terjadi jika semua Aplikasi saya lakukan adalah panggilan ke Firebase. Dan saya tidak bisa memanipulasi kerangka itu. Tapi saya akan meneruskan ini ke tim pengembang Firebase. Mungkin mereka bisa melakukan sesuatu.
David Seek

0

Kami berhasil memecahkan masalah pencatatan ini dengan menonaktifkan HTTP / 2 di server web, dalam kasus kami, kami telah bermigrasi dari ELB klasik ke aplikasi ELB yang menambahkan dukungan ke HTTP / 2 di AWS dan kami mulai mendapatkan "Status Baca TIC [11: 0x0 ]: 1:57 "pada konsol XCode 10.1 / iOS 12. Ini terlihat seperti solusi sementara sampai Apple memperbaiki masalah dengan HTTP / 2 jika ada. Solusi ini mungkin tidak berfungsi untuk semua orang, khususnya jika Anda menggunakan API pihak ketiga, tetapi memberi Anda beberapa wawasan tentang masalah tersebut.


4
Yah sudah 1,5 tahun sekarang sejak Apple memperkenalkan ini ... sebut saja ... fitur ... Saya tidak melihat ini "diperbaiki" dalam waktu dekat.
David Seek

0

Ini adalah logging yang menunjukkan bahwa koneksi TCP hilang / ditutup / not_valid atau apa pun. Ini dapat terjadi jika aplikasi Anda memiliki koneksi tcp yang berjalan dan aplikasi diletakkan di latar belakang untuk beberapa waktu, atau Anda mematikan layar ponsel Anda. OS memutuskan untuk menghentikan sumber daya sebanyak mungkin untuk mengurangi drainase baterai. Jika Anda membawa aplikasi ke latar depan, koneksi-tcp yang Anda miliki sebelumnya, tidak akan berfungsi lagi. Anda perlu membuat ulang koneksi-tcp baru.

Jika itu tidak mengganggu Anda, abaikan saja.

Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.