Giải thích mục nhập Logcat: threadid = 8: vẫn bị treo sau khi hoàn tác (sc = 1 dc = 1 s = Y)

Question

Tôi đang chạy khoảng mười AsyncTasks sau khi ứng dụng của tôi bắt đầu. Đôi khi trình giả lập mất nhiều thời gian để bắt đầu các tác vụ này. Khi điều này xảy ra, tôi thấy thông báo sau trong con mèo log:

D/dalvikvm (1983): threadid = 8: vẫn còn bị đình chỉ sau khi hoàn tác (sc = 1 dc = 1 s = Y)

Khi trình mô phỏng thực hiện nhanh, thông báo này không xuất hiện. Kỳ lạ thay, hành vi này thay đổi ngày hôm nay mà không có bất kỳ sửa đổi nào. Vì tôi đã gán ram 512MB một cách rõ ràng cho trình giả lập, nó không còn cực kỳ chậm ~ 5 phút nữa, bây giờ ~ 5s. Trên một thiết bị thực, tôi chưa bao giờ thực hiện chậm.

Tôi muốn hiểu ý nghĩa của thông điệp nhật ký mèo này. Tôi hiểu rằng chuỗi có id được chỉ định bị tạm ngưng và không hoạt động khi ở trạng thái này. Nhưng tại sao? Sau khi hoàn tác những gì? (Sc = 1 dc = 1 s = Y) có nghĩa là gì?

Answer 1

nhắn này xuất phát từ dvmSuspendSelf(), những chủ đề cuộc gọi khi trình gỡ lỗi (thông qua các chủ đề JDWP) đã yêu cầu họ ngừng.

Cách nó là nghĩa vụ phải làm việc là (nơi "chúng tôi" là một chủ đề):

• JDWP đòi hỏi chúng ta đình chỉ
• chúng tôi nói với nó chúng tôi tạm ngưng và đi ngủ
• cuối cùng , trình gỡ lỗi đánh thức chúng tôi và chúng tôi tiếp tục

Thông báo được ghi lại khi biến điều kiện VM đang chờ tín hiệu, nhưng vì lý do nào đó, chúng tôi vẫn bị đánh dấu là bị tạm ngưng.Mã ghi chú:

/* 
* The condition was signaled but we're still suspended. This 
* can happen if the debugger lets go while a SIGQUIT thread 
* dump event is pending (assuming SignalCatcher was resumed for 
* just long enough to try to grab the thread-suspend lock). 
*/ 

những kỳ vọng trong trường hợp này là chúng ta đã thức dậy bất ngờ khi một tín hiệu đến (ví dụ system_server nghĩ có một ANR vì các chủ đề chính không được đáp ứng vì debugger đã bị đình chỉ nó), và nếu chúng ta lặp lại một lần nữa trình gỡ lỗi sẽ có cơ hội để làm sạch chúng ta và đặt chúng ta trên con đường của chúng ta.

Thông báo tường trình đang in các giá trị self->suspendCount (số lần chúng tôi được yêu cầu tạm ngưng bản thân), self->dbgSuspendCount (số lượng yêu cầu tạm ngưng từ trình gỡ lỗi là bao nhiêu, vì vậy chúng tôi có thể "hoàn tác" tất cả những điều đó nếu trình gỡ rối ngắt kết nối) và giá trị của boolean self->isSuspended.

Lưu ý cờ "s = Y" biến mất trong bánh gừng - cách hoạt động của chuỗi chỉ hoạt động là changed.

Answer 2

Chủ đề này cũ nhưng câu trả lời này sẽ cung cấp hữu ích cho người dùng ngại trong câu hỏi này vài tháng sau đó.

Trích dẫn bài trả lời của người dùng trên google group thread

Có một sự tương tác kỳ lạ giữa VM và gỡ lỗi của bạn. Chủ đề bị treo và sau đó chờ được đánh thức. Tuy nhiên, khi nó được đánh thức, luồng vẫn được đánh dấu là bị treo (s = 1) bởi trình gỡ lỗi (d = 1).

Tôi đã xem qua điều này trên trình giả lập và trên chính điện thoại. Nếu trình gỡ lỗi bị ngắt kết nối khỏi thiết bị (có thể được mô phỏng hoặc thực), điều kiện lỗi này được đặt lại. Tôi đã không tìm thấy cách nào khác để thoát khỏi vấn đề.

Một SO trả lời khẳng định điều này là do breakpoint debug được ra khỏi đồng bộ - DexFile.class error in eclipse

Bạn có thể thử điều đó quá.

HTH

Answer 3

Tôi cũng gặp phải vấn đề. Đơn giản chỉ vì sau khi tôi bắt đầu một Thread mới(), tôi đã cố gắng truy cập các công cụ trong chuỗi đã bị treo. Đã xóa mã đó và sự cố được giải quyết.

HTH