Tôi có một báo cáo tai nạn từ một ứng dụng trực tiếp:Lỗi trong iOS do người dùng khởi tạo qos.overcommit. Điều gì có thể tạo hàng đợi này?
Crashed: com.apple.root.user-initiated-qos.overcommit
0 libobjc.A.dylib 0x21d486c8 objc_release + 7
1 libobjc.A.dylib 0x21d493a9 (anonymous namespace)::AutoreleasePoolPage::pop(void*) + 388
2 libdispatch.dylib 0x22110739 _dispatch_root_queue_drain + 1896
3 libdispatch.dylib 0x2210ffcd _dispatch_worker_thread3 + 96
4 libsystem_pthread.dylib 0x222c5b29 _pthread_wqthread + 1024
5 libsystem_pthread.dylib 0x222c5718 start_wqthread + 8
Các mảnh hữu ích nhất của thông tin có vẻ là tên của hàng đợi rằng vụ tai nạn xảy ra vào lúc: com.apple.root.user-initiated-qos.overcommit
. Tôi đã kiểm tra tất cả mã của mình và tôi sử dụng hàng đợi chính, hàng đợi nền hệ thống (nghĩa là không phải do người dùng tạo ra-qos) hoặc hàng đợi được đặt tên mà tôi tự tạo.
Tôi có các SDK khác đi kèm với ứng dụng của mình để có khả năng công bằng mà các SDK đó có thể được gửi đi hoạt động trên hàng đợi này. Nhưng trước khi tôi giả định rằng đây là trường hợp tôi đã tự hỏi nếu có bất kỳ lý do phổ biến mà iOS chính nó sẽ gửi công việc vào hàng đợi này, có thể giúp tôi cô lập các khu vực của codebase của tôi để kiểm tra chặt chẽ hơn.
Tôi hiểu từ nghiên cứu (WWDC 2015 - Session 718) rằng user-initiated-qos
chất lượng thiết lập dịch vụ có thể được tự động áp dụng cho một hàng đợi khi làm việc là dispatch_async
vào một hàng đợi mà không có một 'chất lượng dịch vụ' cụ thiết lập, từ các chủ đề chính (người dùng tương tác qos). Nhưng như mô tả ở trên, tôi không nghĩ rằng tôi đang làm điều này như tôi tên tất cả các hàng đợi của tôi.
Vì vậy, có ai biết nếu hoặc khi iOS sử dụng hàng đợi com.apple.root.user-initiated-qos.overcommit
không?
Tôi rất muốn biết thêm về hàng đợi overcommit này là tốt. Chúng tôi có rất nhiều sự cố một lần có vẻ như đã xảy ra nhưng tôi chưa thể tìm thấy trường hợp gây ra sự cố. –