การล้มเหลวของแอปบน Mac โดยทั่วไปแล้วค่อนข้างนادرة แต่เมื่อเกิดขึ้น คุณอาจต้องการติดตามสาเหตุ และหากคุณเป็นนักพัฒนา คุณจำเป็นต้องเข้าใจว่าทำไมแอปของคุณถึงล้มเหลว นี่คือวิธีอ่านรายงานข้อผิดพลาด macOS และจัดเรียงภาษาที่ปริศนา
เปิดรายงานข้อผิดพลาด
เมื่อแอปล้มเหลวบน Mac ของคุณ มันจะสร้างรายงานข้อผิดพลาดโดยอัตโนมัติ คุณจะเห็นมันปรากฏหลังจากล้มเหลวพร้อมกล่องโต้ตอบเตือนที่พูดว่า "[App] has quit unexpectedly." รายงานข้อผิดพลาดนั้นพร้อมอ่านทันทีในหน้าต่างนั้นโดยคลิกปุ่ม "Report..." รายงานข้อผิดพลาดยังพบได้ในแอป Console
1. เปิดแอปพลิเคชัน Console โดยพิมพ์ "Console" ลงใน Spotlight หรือไปที่ "Application -> Utilities -> Console.app"
2. คลิก "User Reports" ในเมนูซ้าย แล้วคลิกที่รายงานข้อผิดพลาดที่คุณต้องการดู ไฟล์ทั้งหมดจะลงท้ายด้วย ".crash" และรวมวันที่และแอปพลิเคชันที่ล้มเหลวในชื่อ ไปรายละเอียดของรายงานข้อผิดพลาดพร้อมในแผงด้านขวา
อ่านรายงานข้อผิดพลาด macOS
มาดูรายงานข้อผิดพลาดจากบนลงล่างกัน
อะไรล้มเหลว?
ส่วนแรกของรายงานข้อผิดพลาดบอกคุณว่า "กระบวนการ" (process) หรือแอปพลิเคชันใดล้มเหลว ส่วนสำคัญที่สุดสำหรับผู้แก้ปัญหาทั่วไปคือชื่อกระบวนการ
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
เมื่อไหร่ล้มเหลว?
ส่วนที่สองบอกเราว่าข้อผิดพลาดเกิดขึ้นเมื่อไหร่ มันยังให้ข้อมูลเล็กน้อยเกี่ยวกับระบบของคุณ
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
อะไรทำให้ล้มเหลว?
ส่วนถัดไปเป็นส่วนที่ส่องสว่างที่สุด "ประเภทข้อยกเว้น" (exception type) ที่แอปพลิเคชันให้มา บอกเราว่าสิ่งใดทำให้ล้มเหลว ล็อกยังรายงานว่าธรेडไหนล้มเหลว: ในกรณีนี้คือเธรด 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 แสดงรายการประเภทข้อยกเว้นทั่วไปในเอกสารทางเทคนิคของพวกเขา:
- การเข้าถึงหน่วยความจำที่ผิดปกติ (
EXC_BAD_ACCESS/SIGSEGV/SIGBUS) – โปรแกรมพยายามเข้าถึงหน่วยความจำอย่างไม่ถูกต้องหรือด้วยที่อยู่ที่ไม่ถูกต้อง ต่อท้ายด้วยโค้ดที่อธิบายปัญหาหน่วยความจำ - การออกแบบผิดปกติ (
EXC_CRASH/SIGABRT) – ออกจากโปรแกรมอย่างผิดปกติ โดยทั่วไปจากข้อยกเว้น C++ ที่ไม่ถูกจับและการเรียกabort() - Trace Trap (
EXC_BREAKPOINT/SIGTRAP) – คล้าย SIGABRT แต่ออกจากโปรแกรมนี้ให้ดีบักเกอร์ที่แนบมามีโอกาสหยุดกระบวนการที่จุดหยุด (breakpoint) และติดตามข้อผิดพลาด - คำสั่งผิดกฎหมาย (
EXC_BAD_INSTRUCTION/SIGILL) – กระบวนการออกคำสั่งที่ไม่เข้าใจหรือไม่สามารถประมวลผลได้ - Quit (
SIGQUIT) – กระบวนการถูกยุติโดยกระบวนการอื่นที่มีสิทธิ์เพียงพอ โดยทั่วไปกระบวนการ watchdog ยุติกระบวนการที่ทำงานผิดปกติ - Killed (
SIGKILL) – กระบวนการถูกยุติ بناء על בקשתระบบ รหัสการยุติจะต่อท้ายเพื่ออธิบายข้อยกเว้น
จากรายงานข้อผิดพลาดของเรา เราเห็นว่าแอปพลิเคชันพยายามเข้าถึงหน่วยความจำที่ไม่ได้แมป นี่เกิดจากข้อผิดพลาดในการเขียนโปรแกรมของแอปพลิเคชัน หรือสถานะผู้ใช้ที่ผิดปกติทำให้แอปพลิเคชันแมปหน่วยความจำผิด
อะไรนำไปสู่การล้มเหลว?
หลังจากนั้นเราเห็นรายการตามลำดับเวลาย้อนกลับของสิ่งที่นำไปสู่การล้มเหลว เรียงตามเธรด เริ่มจากเธรด 0
มีคอลัมน์ 4 คอลัมน์ในรายงานนี้ คอลัมน์แรกรายงานหมายเลขเหตุการณ์ในลำดับเวลาย้อนกลับ เริ่มที่ 0 คอลัมน์ที่สองคือตัวระบุกระบวนการ คอลัมน์ที่สามคือที่อยู่ของกระบวนการในหน่วยความจำ คอลัมน์ที่สี่คือชื่องานของโปรแกรม
"Backtrace" นี้อาจทำให้สับสน มัน "symbolicated" หมายความว่าที่อยู่หน่วยความจำบางส่วนถูกแทนที่ด้วยชื่อฟังก์ชันหรืองานของแอปพลิเคชัน บางครั้งทำไม่ได้สมบูรณ์ ทำให้ที่อยู่หน่วยความจำที่อ่านไม่ได้กระจายอยู่ในรายงาน
เราเห็นสิ่งนี้ในรายงานข้อผิดพลาดข้างต้น: com.trankynam.aText ไม่ได้ถูก symbolicated แม้ด้วยการ symbolicated ให้สมบูรณ์ อาจยากที่จะอ่าน backtrace บางครั้งนักพัฒนารวมโน้ตที่มีประโยชน์เกี่ยวกับงานและเหตุการณ์ของแอปพลิเคชัน บางครั้งเป็นชื่อลึกลับหรือโค้ดตัวเลข หากคุณเข้าใจ symbolication ได้ คุณอาจเข้าใจว่ากำลังเกิดอะไรขึ้น แต่ก็เป็นไปได้เท่าๆ กันที่คุณจะต้องเขียนโค้ดแอปพลิเคชันเองจึงจะเข้าใจ backtrace ได้
สรุป: นี่มีประโยชน์ไหม?
หากคุณเป็นนักพัฒนา การอ่านรายงานข้อผิดพลาดเป็นสิ่งจำเป็น มันช่วยให้คุณเข้าใจว่าส่วนไหนของแอปพลิเคชันล้มเหลวและทำไม หากคุณเป็นผู้ใช้ มันไม่ค่อยช่วยได้มาก แต่หากคุณมีข้อผิดพลาดที่ซ้ำซ้อน รายงานข้อผิดพลาดสามารถช่วยคุณแก้ไขปัญหาหรือทำงานกับนักพัฒนาเพื่อแก้ปัญหา คุณอาจได้รหัสข้อผิดพลาดที่มีประโยชน์สำหรับการ Google หรือให้ข้อมูลที่ถูกต้องกับฝ่ายสนับสนุนทางเทคนิค หากคุณต้องการรายละเอียดครบถ้วน คุณสามารถอ่านได้ทั้งหมดในบันดร technical note ของ Apple เกี่ยวกับการล้มเหลว
