GDB เสียหาย stack frame - จะแก้จุดบกพร่องได้อย่างไร?

ฉันมีการติดตามสแต็กต่อไปนี้ เป็นไปได้ไหมที่จะทำสิ่งที่เป็นประโยชน์จากสิ่งนี้สำหรับการดีบัก?

Program received signal SIGSEGV, Segmentation fault.
0x00000002 in ?? ()
(gdb) bt
#0  0x00000002 in ?? ()
#1  0x00000001 in ?? ()
#2  0xbffff284 in ?? ()
Backtrace stopped: previous frame inner to this frame (corrupt stack?)
(gdb) 

จะเริ่มดูโค้ดได้ที่ไหนเมื่อเราได้รับ a Segmentation faultและ stack trace ไม่มีประโยชน์?

หมายเหตุ: หากฉันโพสต์รหัสผู้เชี่ยวชาญ SO จะให้คำตอบแก่ฉัน ฉันต้องการรับคำแนะนำจาก SO และค้นหาคำตอบด้วยตัวเองดังนั้นฉันจึงไม่โพสต์รหัสที่นี่ ขอโทษ.

ที่อยู่ปลอมเหล่านั้น (0x00000002 และอื่น ๆ ) เป็นค่าพีซีไม่ใช่ค่า SP ตอนนี้เมื่อคุณได้รับ SEGV ประเภทนี้พร้อมที่อยู่พีซีปลอม (เล็กมาก) 99% ของเวลาที่เกิดจากการโทรผ่านตัวชี้ฟังก์ชันปลอม โปรดทราบว่าการโทรเสมือนใน C ++ ถูกนำไปใช้ผ่านตัวชี้ฟังก์ชันดังนั้นปัญหาใด ๆ กับการโทรเสมือนสามารถแสดงได้ในลักษณะเดียวกัน

คำสั่งการโทรทางอ้อมเพียงแค่กดพีซีหลังจากการโทรเข้าสู่สแต็กจากนั้นตั้งค่าพีซีเป็นค่าเป้าหมาย (ปลอมในกรณีนี้) ดังนั้นหากนี่คือสิ่งที่เกิดขึ้นคุณสามารถยกเลิกได้อย่างง่ายดายโดยการดึงพีซีออกจากสแต็กด้วยตนเอง . ในรหัส x86 32 บิตคุณเพียงแค่ทำ:

(gdb) set $pc = *(void **)$esp
(gdb) set $esp = $esp + 4

ด้วยรหัส x86 64 บิตที่คุณต้องการ

(gdb) set $pc = *(void **)$rsp
(gdb) set $rsp = $rsp + 8

จากนั้นคุณควรจะสามารถทำbtและหารหัสได้

อีก 1% ของเวลาข้อผิดพลาดจะเกิดจากการเขียนทับสแต็กโดยปกติแล้วอาร์เรย์ที่เก็บไว้ในสแต็กจะล้น ในกรณีนี้คุณอาจได้รับความชัดเจนมากขึ้นเกี่ยวกับสถานการณ์โดยใช้เครื่องมือเช่นvalgrind

หากสถานการณ์ค่อนข้างง่ายคำตอบของ Chris Dodd คือคำตอบที่ดีที่สุด ดูเหมือนว่ามันจะกระโดดผ่านตัวชี้ NULL

อย่างไรก็ตามเป็นไปได้ที่โปรแกรมจะยิงตัวเองที่เท้าเข่าคอและตาก่อนที่จะกระแทก - เขียนทับสแต็กทำให้ตัวชี้กรอบเลอะและความชั่วอื่น ๆ ถ้าเป็นเช่นนั้นการคลี่แฮชไม่น่าจะแสดงให้คุณเห็นมันฝรั่งและเนื้อสัตว์

วิธีแก้ปัญหาที่มีประสิทธิภาพมากขึ้นคือการรันโปรแกรมภายใต้ดีบักเกอร์และก้าวข้ามฟังก์ชันจนกว่าโปรแกรมจะหยุดทำงาน เมื่อระบุฟังก์ชันการหยุดทำงานแล้วให้เริ่มอีกครั้งและเข้าสู่ฟังก์ชันนั้นและพิจารณาว่าฟังก์ชันใดที่เรียกใช้ทำให้เกิดข้อขัดข้อง ทำซ้ำจนกว่าคุณจะพบบรรทัดรหัสที่ละเมิดเพียงบรรทัดเดียว 75% ของเวลาการแก้ไขจะชัดเจน

ในสถานการณ์อื่น ๆ อีก 25% บรรทัดรหัสที่เรียกว่าละเมิดคือปลาชนิดหนึ่งสีแดง มันจะตอบสนองต่อเงื่อนไข (ไม่ถูกต้อง) ที่ตั้งไว้ก่อนหน้านี้หลายบรรทัด - อาจจะเป็นพันบรรทัดก่อนหน้านี้ หากเป็นเช่นนั้นหลักสูตรที่ดีที่สุดที่เลือกขึ้นอยู่กับปัจจัยหลายประการซึ่งส่วนใหญ่คุณเข้าใจรหัสและประสบการณ์กับมัน:

• บางทีการตั้งค่าจุดเฝ้าดูการดีบักเกอร์หรือการแทรกการวินิจฉัยprintfในตัวแปรวิกฤตอาจนำไปสู่A ha ที่จำเป็น!
• บางทีการเปลี่ยนเงื่อนไขการทดสอบด้วยอินพุตที่แตกต่างกันจะให้ข้อมูลเชิงลึกมากกว่าการดีบัก
• บางทีดวงตาคู่ที่สองอาจบังคับให้คุณตรวจสอบสมมติฐานของคุณหรือรวบรวมหลักฐานที่มองข้ามไป
• บางครั้งสิ่งที่ต้องทำก็คือไปทานอาหารเย็นและคิดถึงหลักฐานที่รวบรวมได้

โชคดี!

สมมติว่าตัวชี้สแต็กถูกต้อง ...

อาจเป็นไปไม่ได้ที่จะทราบแน่ชัดว่า SEGV เกิดขึ้นจาก backtrace - ฉันคิดว่าสองสแต็กเฟรมแรกถูกเขียนทับทั้งหมด 0xbffff284 ดูเหมือนจะเป็นที่อยู่ที่ถูกต้อง แต่อีกสองรายการถัดไปไม่ใช่ หากต้องการดูสแต็กอย่างละเอียดยิ่งขึ้นคุณสามารถลองทำสิ่งต่อไปนี้:

gdb $ x / 32ga $ rsp

หรือตัวแปร (แทนที่ 32 ด้วยตัวเลขอื่น) ซึ่งจะพิมพ์คำจำนวนหนึ่ง (32) โดยเริ่มจากตัวชี้สแต็กของขนาดยักษ์ (g) จัดรูปแบบเป็นที่อยู่ (a) พิมพ์ 'help x' เพื่อดูข้อมูลเพิ่มเติมเกี่ยวกับรูปแบบ

การใช้รหัสของคุณเป็นเครื่องมือ 'printf' ของแมวมองอาจไม่ใช่ความคิดที่ไม่ดีในกรณีนี้

ดูทะเบียนอื่น ๆ ของคุณเพื่อดูว่าหนึ่งในนั้นมีตัวชี้สแต็กที่แคชไว้หรือไม่ จากตรงนั้นคุณอาจเรียกคืนสแต็กได้ นอกจากนี้หากมีการฝังสแต็กมักจะกำหนดไว้ที่ที่อยู่ที่เฉพาะเจาะจง เมื่อใช้สิ่งนี้คุณอาจได้รับกองซ้อนที่เหมาะสม ทั้งหมดนี้อนุมานได้ว่าเมื่อคุณกระโดดไปที่ไฮเปอร์สเปซโปรแกรมของคุณจะไม่อ้วกไปทั่วความทรงจำตลอดทาง ...

หากเป็นการเขียนทับสแต็กค่าอาจสอดคล้องกับสิ่งที่จำได้จากโปรแกรม

ตัวอย่างเช่นฉันเพิ่งพบว่าตัวเองกำลังมองไปที่กอง

(gdb) bt
#0  0x0000000000000000 in ?? ()
#1  0x000000000000342d in ?? ()
#2  0x0000000000000000 in ?? ()

และ0x342dคือ 13357 ซึ่งกลายเป็น node-id เมื่อฉัน grepped บันทึกแอปพลิเคชันสำหรับมัน สิ่งนี้ช่วย จำกัด ไซต์ผู้สมัครให้แคบลงในทันทีที่อาจเกิดการเขียนทับสแต็ก