Cách Đọc Báo Cáo Sự Cố (Crash Reports) macOS Để Khắc Phục Sự Cố Mac

Sự cố ứng dụng (app crashes) trên Mac thường khá hiếm. Nhưng khi chúng xảy ra, bạn có thể muốn truy tìm nguyên nhân. Và nếu bạn là nhà phát triển, bạn cần hiểu tại sao ứng dụng của bạn bị sập. Đây là cách đọc báo cáo sự cố macOS và lọc qua ngôn ngữ khó hiểu.

Mở Báo Cáo Sự Cố

Khi một ứng dụng bị sập trên Mac, nó 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 nói "[App] has quit unexpectedly." ([App] đã thoát bất ngờ.) 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 nút "Report..." (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 "User Reports" (Báo cáo người dùng) trong menu trái, sau đó nhấp vào báo cáo sự cố bạn muốn xem. Tất cả các file này sẽ kết thúc bằng ".crash" và bao gồm ngày và ứng dụng bị sập trong tiêu đề. Chi tiết báo cáo sự cố có sẵn trong khung 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.

Cái Gì Đã Bị Sập?

Phần đầu của báo cáo sự cố cho bạn biết "process" (tiến trình) hoặc ứng dụng nào bị sập. Phần quan trọng nhất cho người khắc phục sự cố trung bình là tên tiến trình.

Process: aText [11473]
Path: /Applications/aText.app/Contents/MacOS/aText
Identifier: com.trankynam.aText
Version: 2.19 (62)
Code Type: X86-64 (Native)
Parent Process: ??? [1]
Responsible: aText [11473]
User ID: 501

Khi Nào Nó Bị Sập?

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

Date/Time: 2018-03-15 00:58:10.552 -0400
OS Version: Mac OS X 10.12.6 (16G1036)
Report Version: 12
Anonymous UUID: 6C985CFD-6975-3F30-50EB-0713315F5090
Time Awake Since Boot: 630000 seconds
System Integrity Protection: enabled

Nguyên Nhân Gây Ra Sự Cố Là Gì?

Phần tiếp theo là phần sáng tỏ nhất. "Exception type" (Loại ngoại lệ) do ứng dụng cung cấp cho chúng ta biết nguyên nhân gây ra sự cố. Log cũng báo cáo luồng (thread) nào bị sập: trong trường hợp này, thread 0.

Crashed Thread: 0 Dispatch queue: com.apple.main-thread
Exception Type: EXC_BAD_ACCESS (SIGSEGV)
Exception Codes: KERN_INVALID_ADDRESS at 0x000040dedeadbec0
Exception Note: EXC_CORPSE_NOTIFY
Termination Signal: Segmentation fault: 11
Termination Reason: Namespace SIGNAL, Code 0xb
Terminating Process: 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ớ Sai (EXC_BAD_ACCESS / SIGSEGV / SIGBUS) – chương trình cố truy cập bộ nhớ không đúng cách hoặc với địa chỉ không hợp lệ. Đính kèm 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 do ngoại lệ C++ không được bắt và lời gọi abort().
• Bẫy Dấu Vết (EXC_BREAKPOINT / SIGTRAP) – giống SIGABRT, nhưng thoát này cho trình gỡ lỗi (debugger) đính kèm cơ hội ngắt quá trình tại breakpoint và truy vết lỗi.
• Lệnh Không Hợp Lệ (EXC_BAD_INSTRUCTION / SIGILL) – tiến trình phát ra lệnh không được hiểu hoặc không thể xử lý.
• Thoát (SIGQUIT) – tiến trình bị chấm dứt bởi tiến trình khác với đặc quyền đủ. Thường thì tiến trình watchdog chấm dứt tiến trình hoạt động sai.
• Bị Giết (SIGKILL) – tiến trình bị chấm dứt theo yêu cầu của hệ thống. Mã chấm dứt sẽ được đính kèm để giải thích ngoại lệ.

Như chúng ta thấy từ báo cáo sự cố, ứng dụng cố truy cập bộ nhớ chưa được ánh xạ. Điều này 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 đúng.

Điều Gì Dẫn Đến Sự Cố?

Sau đó chúng ta thấy danh sách theo thứ tự thời gian ngược của những gì dẫn đến sự cố. Chúng được sắp xếp theo luồng, bắt đầu với thread 0.

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

Cái "backtrace" (truy vết ngược) này có thể khá rối. Nó được "symbolicated" (ký hiệu hóa), nghĩa là một số địa chỉ bộ nhớ đã được thay thế bằng tên hàm hoặc nhiệm vụ ứng dụng. Đôi khi điều này không thể làm hoàn toàn, để lại địa chỉ bộ nhớ không đọc được rải rác trong báo cáo.

Chúng ta thấy điều này trong báo cáo sự cố trên: com.trankynam.aText không được ký hiệu hóa. Ngay cả với ký hiệu hóa hoàn chỉnh, đọc backtrace cũng có thể khó. Đôi khi nhà phát triển bao gồm ghi chú hữu ích về nhiệm 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 ký hiệu hóa, bạn có thể hiểu điều gì đang xảy ra. Nhưng cũng có khả năng như nhau rằng bạn sẽ cần tự mình mã hóa ứng dụng để hiểu backtrace.

Kết Luận: Có Hữu Ích Không?

Nếu bạn là nhà phát triển, đọc báo cáo sự cố là thiết yếu. Nó giúp bạn hiểu phần nào của ứng dụng bị sập và tại sao. Nếu bạn là người dùng, chúng không hữu ích bằng. Nhưng nếu bạn có sự cố kiên trì, 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 để sửa lỗi. Bạn có thể nhận được mã lỗi hữu ích để Google hoặc cung cấp cho bộ phận hỗ trợ kỹ thuật thông tin đúng. Nếu bạn muốn chi tiết tường tận, bạn có thể đọc tất cả về nó trong ghi chú kỹ thuật của Apple về sự cố.