Ứng dụng gặp sự cố trên máy Mac thường khá hiếm. Nhưng khi chúng xảy ra, bạn có thể muốn theo dõi nguyên nhân của chúng. Và nếu bạn là nhà phát triển, bạn cần hiểu lý do ứng dụng của bạn gặp sự cố. Đây là cách đọc báo cáo sự cố của macOS và sắp xếp thông qua ngôn ngữ khó hiểu.

Mở báo cáo sự cố

Khi ứng dụng gặp sự cố trên máy Mac, ứng dụng sẽ tự động tạo báo cáo sự cố. Bạn sẽ thấy điều này xuất hiện sau sự cố với hộp thoại cảnh báo cho biết “ [Ứng dụng] đã thoát đột ngột. ”Báo cáo sự cố đó có sẵn để đọc ngay lập tức trong cửa sổ đó bằng cách nhấp vào nút“ Báo cáo… ”. Báo cáo sự cố cũng có thể được tìm thấy trong ứng dụng Console.

1. Mở ứng dụng Console bằng cách gõ "Console" vào Spotlight hoặc điều hướng đến "Application -> Utilities -> Console.app."

2. Nhấp vào “Báo cáo người dùng” ở menu bên trái, sau đó nhấp vào báo cáo sự cố bạn muốn xem. Tất cả các tệp này sẽ kết thúc bằng ".crash" và bao gồm ngày và ứng dụng bị lỗi trong tiêu đề. Chi tiết về báo cáo sự cố có sẵn trong ngăn bên phải.

Đọc báo cáo sự cố macOS

Hãy điều hướng báo cáo sự cố từ trên xuống dưới.

Điều gì đã xảy ra?

Phần đầu tiên của báo cáo sự cố cho bạn biết “quy trình” hoặc ứng dụng nào bị lỗi. Phần quan trọng nhất cho trình khắc phục sự cố trung bình là tên quy trình.

 Quy trình: aText [11473] Đường dẫn: /Ứng dụng/aText.app/Contents/MacOS/aText Mã định danh: com.trankynam.aText Phiên bản: 2.19 (62) Loại mã: Quy trình gốc X86-64 (Gốc): ??? [1] Chịu trách nhiệm: aText [11473] ID người dùng: 501

Khi nào nó sụp đổ?

Phần thứ hai cho chúng ta biết khi nào vụ tai nạn xảy ra. Nó cũng cung cấp một ít thông tin về hệ thống của bạn.

 Ngày / Giờ: 2018-03-15 00: 58: 10.552 -0400 Phiên bản hệ điều hành: Mac OS X 10.12.6 (16G1036) Báo cáo Phiên bản: 12 Chưa xác định UUID: 6C985CFD-6975-3F30-50EB-0713315F5090 Thời gian Tỉnh Thức Kể từ khi khởi động: 630000 giây Bảo vệ toàn vẹn hệ thống: đã bật

Điều gì gây ra sự cố?

Phần tiếp theo là chiếu sáng nhất. "Loại ngoại lệ" do ứng dụng cung cấp cho chúng tôi biết nguyên nhân gây ra sự cố. Nhật ký cũng báo cáo chuỗi nào bị lỗi: trong trường hợp này, chuỗi 0.

 Crashed Thread: 0 Dispatch queue: com.apple.main-thread Loại ngoại lệ: EXC_BAD_ACCESS (SIGSEGV) Các mã ngoại lệ: KERN_INVALID_ADDRESS tại 0x000040dedeadbec0 Lưu ý ngoại lệ: EXC_CORPSE_NOTIFY Tín hiệu chấm dứt: Lỗi phân đoạn: 11 Lý do chấm dứt: Dấu hiệu không gian tên, Mã 0xb Quy trình chấm dứt: exc handler [0]

Apple liệt kê một số loại ngoại lệ phổ biến trong tài liệu kỹ thuật của họ:

  • Truy cập bộ nhớ kém ( EXC_BAD_ACCESS / SIGSEGV / SIGBUS ) - chương trình tìm cách truy cập bộ nhớ không chính xác hoặc với địa chỉ không hợp lệ. Được nối thêm bằng mã giải thích vấn đề bộ nhớ.
  • Thoát bất thường ( EXC_CRASH / SIGABRT ) - thoát bất thường, thường ở bàn tay của một ngoại lệ C ++ không bị bắt và các cuộc gọi abort()
  • Trace Trap ( EXC_BREAKPOINT / SIGTRAP ) - giống như SIGABRT, nhưng lối ra này cung cấp cho trình gỡ rối đính kèm cơ hội làm gián đoạn quá trình tại điểm ngắt và theo dõi lỗi.
  • Hướng dẫn bất hợp pháp ( EXC_BAD_INSTRUCTION / SIGILL ) - lệnh đã xử lý đã ban hành một lệnh không được hiểu hoặc không thể xử lý được.
  • Thoát ( SIGQUIT ) - quá trình đã bị chấm dứt bởi một tiến trình khác với đủ đặc quyền. Thông thường, một quy trình giám sát chấm dứt một quá trình không đúng.
  • Bị giết ( SIGKILL ) - quá trình đã bị chấm dứt theo yêu cầu của hệ thống. Mã chấm dứt sẽ được thêm vào để giải thích ngoại lệ.

Như chúng ta có thể thấy từ báo cáo sự cố của chúng tôi, ứng dụng đã cố truy cập bộ nhớ chưa được ánh xạ. Điều này là do lỗi lập trình trong ứng dụng hoặc trạng thái người dùng bất thường khiến ứng dụng ánh xạ bộ nhớ không chính xác.

Điều gì dẫn đến vụ tai nạn?

Sau đó, chúng ta thấy một danh sách thời gian ngược về những gì dẫn đến vụ tai nạn. Chúng được sắp xếp theo chuỗi, bắt đầu bằng chuỗi 0.

Có bốn cột cho báo cáo này. Đầu tiên báo cáo số của sự kiện theo thứ tự thời gian đảo ngược, bắt đầu từ 0. Thứ hai là số nhận dạng của quá trình. Thứ ba là địa chỉ của quá trình trong bộ nhớ. Thứ tư là tên của nhiệm vụ của chương trình.

"Backtrace" này có thể hơi khó hiểu. Đó là “tượng trưng”, nghĩa là một số địa chỉ bộ nhớ đã được thay thế bằng các tên hàm hoặc các nhiệm vụ ứng dụng. Đôi khi điều này không thể được thực hiện hoàn toàn, để lại các địa chỉ bộ nhớ không đọc được nằm rải rác thông qua báo cáo.

Chúng tôi thấy điều này trong báo cáo sự cố ở trên: com.trankynam.aText không phải là biểu tượng. Ngay cả với biểu tượng hoàn chỉnh, nó có thể được khó khăn để đọc backtrace. Đôi khi các nhà phát triển bao gồm các ghi chú hữu ích về các tác vụ và sự kiện ứng dụng. Lần khác, chúng là tiêu đề bí ẩn hoặc mã số. Nếu bạn có thể hiểu được biểu tượng, bạn có thể hiểu những gì đang xảy ra. Nhưng nó là bằng nhau nhất có thể mà bạn sẽ cần phải có mã hóa các ứng dụng chính mình để làm cho tinh thần của backtrace.

Kết luận: Điều này có hữu ích không?

Nếu bạn là nhà phát triển, hãy đọc báo cáo sự cố là điều cần thiết. Nó giúp bạn hiểu những gì một phần của ứng dụng của bạn bị rơi và tại sao. Nếu bạn là người dùng, họ không hữu ích. Nhưng nếu bạn gặp sự cố liên tục, báo cáo sự cố có thể giúp bạn khắc phục sự cố hoặc làm việc với nhà phát triển để khắc phục sự cố. Bạn có thể nhận được mã lỗi hữu ích cho Google hoặc có thể cung cấp hỗ trợ kỹ thuật với thông tin phù hợp. Nếu bạn muốn các chi tiết đẫm máu, bạn có thể đọc tất cả về nó trong ghi chú kỹ thuật của Apple về tai nạn.