Các lỗi ứng dụng trên Mac nói chung là khá hiếm. Nhưng khi chúng xảy ra, bạn có thể muốn tìm ra 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 tại sao ứng dụng của bạn gặp sự cố. Dưới đây là cách đọc báo cáo sự cố macOS và sắp xếp theo ngôn ngữ khó hiểu.
Mở báo cáo sự cố
Khi một ứng dụng gặp sự cố trên máy Mac của bạn, nó sẽ tự động tạo một 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ạn có thể đọc ngay báo cáo sự cố đó trong cửa sổ đó bằng cách nhấp vào nút“ Báo cáo… ”. Bạn cũng có thể tìm thấy báo cáo sự cố trong ứng dụng Bảng điều khiển.
1. Mở ứng dụng Console bằng cách nhập “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 tháng và ứng dụng bị lỗi trong tiêu đề. Chi tiết của 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.
Sự cố gì?
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 bị lỗi nào. Phần quan trọng nhất đối với trình khắc phục sự cố trung bình là tên quy 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
Nó bị lỗi khi nào?
Phần thứ hai cho chúng ta biết khi 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.
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
Điều gì đã gây ra sự cố?
Phần tiếp theo là phần 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 điều gì đã gây ra sự cố. Nhật ký cũng báo cáo luồng nào bị lỗi:trong trường hợp này là luồng 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ớ Không hợp lệ (
EXC_BAD_ACCESS/SIGSEGV/SIGBUS) - chương trình cố gắng truy cập bộ nhớ không chính xác hoặc với một địa chỉ không hợp lệ. Được thêm mã giải thích sự cố bộ nhớ. - Thoát bất thường (
EXC_CRASH/SIGABRT) - lối ra bất thường, thường là do ngoại lệ C ++ chưa tìm thấy và các lệnh gọi đếnabort() - Trap Trap (
EXC_BREAKPOINT/SIGTRAP) - giống như SIGABRT, nhưng lối ra này cho phép trình gỡ lỗi đính kèm có cơ hội làm gián đoạn quá trình tại một điểm ngắt và theo dõi lỗi. - Hướng dẫn Bất hợp pháp (
EXC_BAD_INSTRUCTION/SIGILL) - đã xử lý đưa ra một hướng dẫn không được hiểu hoặc không thể xử lý được. - Thoát (
SIGQUIT) - quy trình đã bị kết thúc bởi một quy trình khác có đủ đặc quyền. Thông thường, một quy trình của cơ quan giám sát sẽ chấm dứt một quy trình hoạt động sai. - Bị giết (
SIGKILL) - quá trình đã được kết thúc theo yêu cầu của hệ thống. Một mã kết thúc 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 mình, ứng dụng đã cố gắng 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 sự cố?
Sau đó, chúng tôi thấy một danh sách theo trình tự thời gian đảo ngược về những gì dẫn đến vụ tai nạn. Chúng được sắp xếp theo chủ đề, bắt đầu bằng chủ đề 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 quy trình. Thứ ba là địa chỉ của tiến trình trong bộ nhớ. Thứ tư là tên nhiệm vụ của chương trình.
“Nền tảng” này có thể hơi khó hiểu. Nó được "biểu tượng hóa", nghĩa là một số địa chỉ bộ nhớ đã được thay thế bằng tên chức năng hoặc tác 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 thể đọc được nằm rải rác trong 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 được tượng trưng. Ngay cả khi có biểu tượng đầy đủ, có thể khó đọc dấu vết. Đôi khi các nhà phát triển bao gồm các ghi chú hữu ích về các nhiệm vụ và sự kiện của ứng dụng. Những lần khác, chúng là tiêu đề hoặc mã số khó hiểu. Nếu bạn có thể hiểu được biểu tượng, bạn có thể hiểu được điều gì đang xảy ra. Nhưng cũng không kém phần có thể là bạn cần phải tự mình mã hóa ứng dụng để hiểu rõ về lỗi.
Kết luận:Điều này có hữu ích không?
Nếu bạn là nhà phát triển, việc đọc báo cáo sự cố là điều cần thiết. Nó giúp bạn hiểu phần nào ứng dụng của bạn gặp sự cố 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 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 biết 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ề sự cố.