2016-05-24 25 views
7

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?

+0

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ố. –

Trả lời

2

Đây là hàng đợi mặc định được tạo bởi hệ thống. Các thành phần giao diện người dùng và thành phần hệ thống khác nhau gửi các khối tới hàng đợi này.

Khi bạn thấy sự cố với _dispatch_root_queue_drain trong theo dõi ngăn xếp, điều đó có nghĩa là một số khối đã được thực hiện trên hàng đợi đó và hồ bơi tự động thoát. Thông thường vụ tai nạn là do phát hành một đối tượng đã được phát hành, nó chỉ như vậy sẽ xảy ra phát hành "thêm" kết thúc lên do hồ bơi autorelease vì nó chạy cuối cùng.

Tỷ lệ cược là bạn đã đưa ra một đối tượng cho một khung hệ thống ở đâu đó nhưng nó vô tình bị quá tải.

chỉnh sửa: Here are instructions cho việc sử dụng NSZombie để theo dõi những xuống

Các vấn đề liên quan