แก้จุดบกพร่อง

จากวิกิพีเดีย สารานุกรมเสรี
ข้ามไปที่การนำทาง ข้ามไปที่การค้นหา

ในการเขียนโปรแกรมคอมพิวเตอร์และการพัฒนาซอฟต์แวร์ การดีบักเป็นกระบวนการในการค้นหาและแก้ไข จุด บกพร่อง (ข้อบกพร่องหรือปัญหาที่ขัดขวางการทำงานที่ถูกต้อง) ภายใน โปรแกรมคอมพิวเตอร์ซอฟต์แวร์หรือระบบ

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

นิรุกติศาสตร์

รายการบันทึกคอมพิวเตอร์จาก Mark II โดยมีมอดติดเทปไว้ที่หน้า

คำว่า "บั๊ก" และ "การดีบัก" มักใช้กันอย่างแพร่หลาย ในสมัยของ พลเรือเอกเกรซ ฮอปเปอร์ในทศวรรษ 1940 [1]ขณะที่เธอทำงานกับ คอมพิวเตอร์ Mark IIที่มหาวิทยาลัยฮาร์วาร์ด เพื่อนร่วมงานของเธอพบว่าตัวมอดติดอยู่ในรีเลย์และขัดขวางการทำงาน ดังนั้นเธอจึงตั้งข้อสังเกตว่าพวกเขากำลัง "ดีบั๊ก" ระบบ อย่างไรก็ตาม คำว่า "จุดบกพร่อง" ในแง่ของ "ข้อผิดพลาดทางเทคนิค" มีขึ้นอย่างน้อยในปี พ.ศ. 2421 และโธมัส เอดิสัน (ดู จุด บกพร่องของซอฟต์แวร์สำหรับการสนทนาแบบเต็ม) ในทำนองเดียวกัน คำว่า "การดีบัก" ดูเหมือนจะถูกใช้เป็นคำศัพท์ทางวิชาการบินก่อนเข้าสู่โลกของคอมพิวเตอร์ อันที่จริงในการให้สัมภาษณ์ Grace Hopper ตั้งข้อสังเกตว่าเธอไม่ได้เป็นผู้กำหนดคำศัพท์นี้มอดพอดีกับคำศัพท์ที่มีอยู่แล้วดังนั้นจึงถูกบันทึกไว้ จดหมายจากเจ. โรเบิร์ต ออพเพนไฮเม อร์ (ผู้อำนวยการ โครงการแมนฮัตตันระเบิดปรมาณูสงครามโลกครั้งที่สองที่ลอสอาลามอส นิวเม็กซิโก) ใช้คำนี้ในจดหมายถึงดร. เออร์เนสต์ ลอว์เรนซ์ที่ UC Berkeley ลงวันที่ 27 ตุลาคม พ.ศ. 2487 [2]เกี่ยวกับการรับสมัคร ของเจ้าหน้าที่ด้านเทคนิคเพิ่มเติม

รายการพจนานุกรมภาษาอังกฤษของ Oxfordสำหรับคำว่า "debug" อ้างอิงคำว่า "debugging" ที่ใช้ในการอ้างอิงถึงการทดสอบเครื่องยนต์เครื่องบินในบทความปี 1945 ในวารสาร Royal Aeronautical Society บทความใน "Airforce" (มิถุนายน 2488 หน้า 50) ยังหมายถึงการดีบักครั้งนี้ของกล้องอากาศยาน พบ บั๊กของฮอปเปอร์เมื่อวันที่ 9 กันยายน พ.ศ. 2490 โปรแกรมเมอร์คอมพิวเตอร์ไม่ได้ใช้คำนี้จนกระทั่งต้นทศวรรษ 1950 บทความเชิงลึกโดย Gill [3]ในปี 1951 เป็นการอภิปรายเชิงลึกเกี่ยวกับข้อผิดพลาดในการเขียนโปรแกรมที่เก่าแก่ที่สุด แต่ไม่ได้ใช้คำว่า "bug" หรือ "debugging" ในห้องสมุดดิจิทัลของACM คำว่า "การดีบัก" ถูกใช้ครั้งแรกในเอกสารสามฉบับจากการประชุมระดับชาติ ACM ปี 1952สองในสามใช้คำนี้ในเครื่องหมายคำพูด ภายในปี 1963 "การดีบัก" เป็นคำสามัญ-เพียงพอที่จะกล่าวถึงในการผ่านโดยไม่มีคำอธิบายในหน้า 1 ของคู่มือCTSS [7]

บทความของPeggy A. Kidwell Stalking the Elusive Computer Bug [8]กล่าวถึงนิรุกติศาสตร์ของ "bug" และ "debug" ในรายละเอียดมากขึ้น

ขอบเขต

เนื่องจากซอฟต์แวร์และระบบอิเล็กทรอนิกส์โดยทั่วไปมีความซับซ้อนมากขึ้น เทคนิคการดีบักทั่วไปต่างๆ จึงได้ขยายออกไปด้วยวิธีการอื่นๆ ในการตรวจจับความผิดปกติ ประเมินผลกระทบ และกำหนดเวลา แพต ช์ซอฟต์แวร์หรืออัปเดตระบบทั้งหมด คำว่า "ความผิดปกติ" และ "ความคลาดเคลื่อน" สามารถใช้เป็นคำที่เป็นกลางมากกว่าเพื่อหลีกเลี่ยงคำว่า "ข้อผิดพลาด" และ "ข้อบกพร่อง" หรือ "ข้อบกพร่อง" ซึ่งอาจมีนัยยะที่เรียกว่าข้อผิดพลาดข้อบกพร่องหรือข้อบกพร่องจะต้องได้รับการแก้ไข (ค่าใช้จ่ายทั้งหมด) แต่ สามารถ ทำการประเมินผลกระทบเพื่อพิจารณาว่าการเปลี่ยนแปลงเพื่อขจัดสิ่งผิดปกติ ออก (หรือความคลาดเคลื่อน) จะคุ้มทุนสำหรับระบบ หรือบางทีการเปิดตัวใหม่ตามกำหนดเวลาอาจทำให้การเปลี่ยนแปลงไม่จำเป็น ไม่ใช่ทุกประเด็นที่มีความสำคัญต่อความปลอดภัยหรือ มีความสำคัญต่อ ภารกิจในระบบ นอกจากนี้ สิ่งสำคัญคือต้องหลีกเลี่ยงสถานการณ์ที่การเปลี่ยนแปลงอาจทำให้ผู้ใช้ไม่พอใจในระยะยาว มากกว่าการใช้ชีวิตกับปัญหาที่ทราบ (ซึ่ง "การรักษาจะแย่กว่าโรค") การตัดสินใจบนพื้นฐานของการยอมรับของความผิดปกติบางอย่างสามารถหลีกเลี่ยงวัฒนธรรมของคำสั่ง "ไม่มีข้อบกพร่อง" ซึ่งผู้คนอาจถูกล่อลวงให้ปฏิเสธการมีอยู่ของปัญหาเพื่อให้ผลลัพธ์ปรากฏเป็นศูนย์ข้อบกพร่อง. เมื่อพิจารณาถึงประเด็นหลักประกัน เช่น การประเมินผลกระทบด้านต้นทุนเทียบกับผลประโยชน์ เทคนิคการดีบักที่กว้างขึ้นจะขยายออกไปเพื่อกำหนดความถี่ของความผิดปกติ (บ่อยครั้งที่ "จุดบกพร่อง" เดียวกันเกิดขึ้น) เพื่อช่วยประเมินผลกระทบต่อระบบโดยรวม

เครื่องมือ

การดีบักบนคอนโซลวิดีโอเกมมักจะทำด้วยฮาร์ดแวร์พิเศษ เช่นหน่วยดีบักXbox นี้สำหรับนักพัฒนา

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

โดยทั่วไปภาษาโปรแกรมระดับสูงเช่นJavaทำให้การดีบักง่ายขึ้น เนื่องจากมีคุณลักษณะต่างๆ เช่นการจัดการข้อยกเว้นและ การ ตรวจสอบประเภทที่ทำให้มองเห็นแหล่งที่มาของพฤติกรรมที่ผิดปกติได้ง่ายขึ้น ในภาษาการเขียนโปรแกรมเช่นCหรือแอสเซมบลีบั๊กอาจทำให้เกิดปัญหาเงียบ ๆ เช่นหน่วยความจำเสียหายและมักจะยากที่จะดูว่าปัญหาเริ่มต้นเกิดขึ้นที่ใด ในกรณีดังกล่าวอาจจำเป็นต้องใช้เครื่องมือ ดีบักเกอร์หน่วยความจำ

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

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

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

ขั้นตอนการแก้จุดบกพร่อง

โดยปกติ ขั้นตอนแรกในการดีบักคือการพยายามทำให้เกิดปัญหาซ้ำ นี่อาจเป็นงานที่ไม่สำคัญ เช่น กับกระบวนการคู่ขนานและHeisenbugs บาง ตัว นอกจากนี้ สภาพแวดล้อมของผู้ใช้เฉพาะและประวัติการใช้งานอาจทำให้เกิดปัญหาซ้ำได้ยาก

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

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

เทคนิค

  • การดีบักเชิงโต้ตอบ
  • การ ดีบักการพิมพ์ (หรือการติดตาม) เป็นการกระทำของการดูคำสั่งการติดตาม (สดหรือที่บันทึกไว้) หรือคำสั่งการพิมพ์ ซึ่งระบุถึงโฟลว์ของการดำเนินการของกระบวนการ นี้บางครั้งเรียกว่าการ ดีบัก printfเนื่องจากการใช้printfใน C การดีบักประเภทนี้ถูกเปิดใช้งานโดยคำสั่ง TRON ในเวอร์ชันดั้งเดิมของภาษาการเขียนโปรแกรมพื้นฐานTRON ย่อมาจาก "Trace On" TRON ทำให้หมายเลขบรรทัดของบรรทัดคำสั่งพื้นฐานแต่ละบรรทัดพิมพ์ขณะที่โปรแกรมทำงาน
  • การดีบักระยะไกลเป็นกระบวนการของการดีบักโปรแกรมที่ทำงานบนระบบที่แตกต่างจากตัวดีบั๊ก เมื่อต้องการเริ่มต้นการดีบักแบบรีโมต ดีบักเกอร์จะเชื่อมต่อกับระบบรีโมตผ่านลิงก์การสื่อสาร เช่น เครือข่ายท้องถิ่น ดีบักเกอร์สามารถควบคุมการทำงานของโปรแกรมบนระบบระยะไกลและดึงข้อมูลเกี่ยวกับสถานะของโปรแกรมได้
  • การดีบักชันสูตรพลิกศพเป็นการดีบักของโปรแกรมหลังจากที่เกิดความผิดพลาดขึ้นแล้ว เทคนิคที่เกี่ยวข้องมักรวมถึงเทคนิคการติดตามต่างๆ เช่น การตรวจสอบไฟล์บันทึก การแสดงcall stackเมื่อเกิดความผิดพลาด[9]และการวิเคราะห์การถ่ายโอนข้อมูลหน่วยความจำ (หรือcore dump ) ของกระบวนการที่ขัดข้อง ระบบสามารถรับดัมพ์ของกระบวนการได้โดยอัตโนมัติ (เช่น เมื่อกระบวนการสิ้นสุดลงเนื่องจากข้อยกเว้นที่ไม่สามารถจัดการได้) หรือโดยคำสั่งที่โปรแกรมเมอร์แทรกไว้ หรือโดยผู้ใช้แบบโต้ตอบด้วยตนเอง
  • อัลกอริธึม "รั้วหมาป่า": Edward Gauss อธิบายอัลกอริทึมที่เรียบง่ายแต่มีประโยชน์มากและตอนนี้มีชื่อเสียงในบทความปี 1982 สำหรับการสื่อสารของ ACMดังนี้: "มีหมาป่าตัวหนึ่งในอลาสก้า คุณหามันเจอได้อย่างไร ขั้นแรกให้สร้างรั้วตรงกลาง ของรัฐ รอให้หมาป่าหอน พิจารณาว่ารั้วอยู่ด้านใด ทำซ้ำเฉพาะด้านนั้นเท่านั้น จนกว่าคุณจะไปถึงจุดที่มองเห็นหมาป่าได้" [10]นี้ถูกนำมาใช้เช่นในระบบควบคุมเวอร์ชันGit เป็นคำสั่งgit bisectซึ่งใช้อัลกอริธึมข้างต้นเพื่อพิจารณาว่าการกระทำใดทำให้เกิดข้อผิดพลาดโดยเฉพาะ
  • การดีบักบันทึกและเล่นซ้ำ เป็นเทคนิคในการสร้างการบันทึกการทำงานของโปรแกรม (เช่น การใช้เครื่องมือดีบัก rrฟรีของ Mozilla การเปิดใช้งานการดีบักแบบย้อนกลับ/การดำเนินการ) ซึ่งสามารถเล่นซ้ำและดีบั๊กแบบโต้ตอบได้ มีประโยชน์สำหรับการดีบักระยะไกลและการดีบักข้อบกพร่องเป็นระยะๆ ที่ไม่ได้กำหนดไว้ และข้อบกพร่องอื่นๆ ที่ยากต่อการทำซ้ำ
  • การดีบักเดลต้า  – เทคนิคการทำให้กรณีทดสอบง่ายขึ้นโดยอัตโนมัติ [11] : น.123 
  • Saff Squeeze  – เทคนิคการแยกความล้มเหลวภายในการทดสอบโดยใช้การแทรกส่วนต่างๆ ของการทดสอบที่ล้มเหลวแบบก้าวหน้า [12] [13]
  • การติดตามสาเหตุ : มีเทคนิคในการติดตามห่วงโซ่ผลกระทบในการคำนวณ [14]เทคนิคเหล่านี้สามารถปรับให้เหมาะกับจุดบกพร่องเฉพาะ เช่น การยกเลิกการอ้างอิงตัวชี้ null [15] [16]

การดีบักสำหรับระบบฝังตัว

ในทางตรงกันข้ามกับสภาพแวดล้อมการออกแบบซอฟต์แวร์คอมพิวเตอร์ที่ใช้งานทั่วไป คุณลักษณะหลักของสภาพแวดล้อมแบบฝังคือจำนวนแพลตฟอร์มที่แตกต่างกันสำหรับนักพัฒนา (สถาปัตยกรรม CPU ผู้ขาย ระบบปฏิบัติการ และตัวแปร) ตามคำจำกัดความแล้ว ระบบสมองกลฝังตัวไม่ใช่การออกแบบสำหรับวัตถุประสงค์ทั่วไป โดยทั่วไปแล้วระบบดังกล่าวจะได้รับการพัฒนาสำหรับงานเดียว (หรืองานเล็กๆ น้อยๆ) และเลือกแพลตฟอร์มเพื่อเพิ่มประสิทธิภาพแอปพลิเคชันนั้นโดยเฉพาะ ข้อเท็จจริงนี้ไม่เพียงแต่ทำให้ชีวิตยากขึ้นสำหรับนักพัฒนาระบบฝังตัว แต่ยังทำให้การดีบักและการทดสอบระบบเหล่านี้ยากขึ้นเช่นกัน เนื่องจากเครื่องมือการดีบักต่างๆ จำเป็นสำหรับแพลตฟอร์มที่แตกต่างกัน

แม้จะมีความท้าทายในเรื่องความหลากหลายที่กล่าวไว้ข้างต้น แต่ตัวดีบั๊กบางตัวก็ได้รับการพัฒนาในเชิงพาณิชย์เช่นเดียวกับต้นแบบการวิจัย ตัวอย่างของโซลูชันเชิงพาณิชย์มาจากGreen Hills Software [ 17] Lauterbach GmbH [18]และ MPLAB-ICD ของ Microchip (สำหรับดีบักเกอร์ในวงจร) ตัวอย่างเครื่องมือต้นแบบการวิจัย 2 ตัวอย่าง ได้แก่ Aveksha [19]และ Flocklab [20]พวกเขาทั้งหมดใช้ประโยชน์จากฟังก์ชันที่มีอยู่ในโปรเซสเซอร์ฝังตัวราคาถูก ซึ่งเป็นโมดูลดีบักบนชิป (OCDM) ซึ่งสัญญาณจะถูกเปิดเผยผ่านอินเทอร์เฟซ JTAGมาตรฐาน มีการเปรียบเทียบโดยพิจารณาจากการเปลี่ยนแปลงที่จำเป็นต่อแอปพลิเคชันและอัตราของเหตุการณ์ที่พวกเขาสามารถติดตามได้

นอกเหนือจากงานทั่วไปในการระบุจุดบกพร่องในระบบแล้ว การดีบักระบบฝังตัวยังพยายามรวบรวมข้อมูลเกี่ยวกับสถานะการทำงานของระบบที่อาจใช้ในการวิเคราะห์ระบบ: เพื่อหาวิธีเพิ่มประสิทธิภาพหรือเพิ่มประสิทธิภาพที่สำคัญอื่นๆ ลักษณะเฉพาะ (เช่น การใช้พลังงาน ความน่าเชื่อถือ การตอบสนองแบบเรียลไทม์ ฯลฯ)

ป้องกันการดีบัก

การต่อต้านการดีบักคือ "การนำเทคนิคหนึ่งอย่างขึ้นไปมาใช้ในโค้ดคอมพิวเตอร์ที่ขัดขวางความพยายามในการทำวิศวกรรมย้อนกลับหรือการดีบักกระบวนการเป้าหมาย" [21]มันถูกใช้อย่างแข็งขันโดยผู้เผยแพร่ที่รู้จักใน สคีมา ป้องกันการคัดลอกแต่ยังถูกใช้โดยมัลแวร์เพื่อทำให้การตรวจจับและกำจัดมันซับซ้อน [22]เทคนิคที่ใช้ในการต่อต้านการดีบัก ได้แก่ :

  • อิงตาม API: ตรวจสอบการมีอยู่ของดีบักเกอร์โดยใช้ข้อมูลระบบ
  • ตามข้อยกเว้น: ตรวจสอบเพื่อดูว่ามีการแทรกแซงข้อยกเว้นหรือไม่
  • บล็อกกระบวนการและเธรด: ตรวจสอบว่ามีการจัดการบล็อกกระบวนการและเธรดหรือไม่
  • แก้ไขโค้ด: ตรวจสอบการแก้ไขโค้ดที่ทำโดยดีบักเกอร์จัดการจุดพักซอฟต์แวร์
  • ฮาร์ดแวร์และการลงทะเบียน: ตรวจสอบจุดหยุดของฮาร์ดแวร์และการลงทะเบียน CPU
  • เวลาและเวลาแฝง: ตรวจสอบเวลาที่ใช้สำหรับการดำเนินการตามคำสั่ง
  • การตรวจจับและลงโทษดีบัก[22]

ตัวอย่างแรก ๆ ของการต่อต้านการดีบักมีอยู่ในMicrosoft Word เวอร์ชันแรก ๆ ซึ่งหากตรวจพบโปรแกรมดีบั๊ก จะสร้างข้อความว่า "ต้นไม้แห่งความชั่วร้ายมีผลขม ตอนนี้กำลังทิ้งดิสก์ของโปรแกรม" หลังจากนั้นก็ทำให้เกิดฟลอปปี้ ดิสก์ไดรฟ์เพื่อส่งเสียงที่น่าตกใจโดยมีจุดประสงค์เพื่อทำให้ผู้ใช้กลัวจากการพยายามอีกครั้ง [23] [24]

ดูเพิ่มเติม

อ้างอิง

  1. ^ "InfoWorld 5 ต.ค. 2524" . 5 ตุลาคม 2524 เก็บถาวรจากต้นฉบับเมื่อ 18 กันยายน 2562 . สืบค้นเมื่อ17 กรกฎาคม 2019 .
  2. ^ "สำเนาที่เก็บถาวร" . เก็บถาวรจากต้นฉบับเมื่อ 2019-11-21 . สืบค้นเมื่อ2019-12-17 .{{cite web}}: CS1 maint: archived copy as title (link)
  3. S. Gill, The Diagnosis of Mistakes in Programs on the EDSAC Archived 2020-03-06 at the Wayback Machine , Proceedings of the Royal Society of London. ซีรีส์ A คณิตศาสตร์และวิทยาศาสตร์กายภาพ เล่ม 1 206, No. 1087 (22 พฤษภาคม 2494), หน้า 538-554
  4. ^ Robert VD Campbell, Evolution of automatic computation Archived 2019-09-18 at the Wayback Machine , Proceedings of the 1952 ACM national meeting (Pittsburgh), p 29-32, 1952.
  5. อเล็กซ์ ออร์เดนวิธีแก้ปัญหาระบบความไม่เท่าเทียมกันเชิงเส้นบนคอมพิวเตอร์ดิจิทัลการดำเนินการประชุมระดับชาติ ACM ปี 1952 (พิตต์สเบิร์ก) หน้า 91-95, 2495.
  6. Howard B. Demuth, John B. Jackson, Edmund Klein, N. Metropolis, Walter Orvedahl, James H. Richardson, MANIAC doi=10.1145/800259.808982, Proceedings of the 1952 ACM national meeting (โตรอนโต), p. 13-16
  7. ^ The Compatible Time-Sharing System Archived 2012-05-27 ที่ Wayback Machine , MIT Press, 1963
  8. เพ็กกี้ อัลดริช คิดเวลล์, Stalking the Elusive Computer Bug , IEEE Annals of the History of Computing, 1998
  9. ^ "การดีบักชันสูตรพลิกศพ" . เก็บถาวรจากต้นฉบับเมื่อ 2019-12-17 . สืบค้นเมื่อ2019-12-17 .
  10. อีเจ เกาส์ (1982). แบบฝึกหัด: อัลกอริธึม 'รั้วหมาป่า' สำหรับการดีบัก " การสื่อสาร ของACM 25 (11): 780. ดอย : 10.1145/358690.358695 . S2CID 672811 . 
  11. ^ เซลเลอร์, อันเดรียส (2005). เหตุใดโปรแกรมจึงล้มเหลว: คู่มือการดีบักอย่าง เป็นระบบ มอร์แกน คอฟมันน์. ISBN 1-55860-866-4.
  12. "Kent Beck, Hit 'em High, Hit 'em Low: การทดสอบการถดถอยและ Saff Squeeze " เก็บถาวรจากต้นฉบับเมื่อ 2012-03-11
  13. ^ Rainsberger, เจบี"The Saff Squeeze " รหัสกระซิบ. สืบค้นเมื่อ28 มีนาคม 2022 .
  14. ^ เซลเลอร์, อันเดรียส (2002-11-01). "การแยกสายเหตุ-ผลออกจากโปรแกรมคอมพิวเตอร์". หมายเหตุวิศวกรรม ซอฟต์แวร์ACM SIGSOFT 27 (6): 1–10. ดอย : 10.1145/605466.605468 . ISSN 0163-5948 . S2CID 12098165 .  
  15. ^ บอนด์ ไมเคิล ดี.; Nethercote, นิโคลัส; เคนท์, สตีเฟน ดับเบิลยู.; กายเออร์, ซามูเอล ซี.; แมคคินลีย์, แคทรีน เอส. (2007). "ติดตามแอปเปิ้ลที่ไม่ดี". การดำเนินการของการประชุม ACM SIGPLAN ประจำปีครั้งที่ 22 เกี่ยวกับระบบและแอปพลิเคชันการเขียนโปรแกรมเชิงวัตถุ - OOPSLA '07 หน้า 405. ดอย : 10.1145/1297027.1297057 . ISBN 9781595937865. S2CID  2832749 .
  16. ^ คอร์นู เบอนัวต์; Barr เอิร์ล T.; Seinturier, ไลโอเนล; มอนเพอร์รัส, มาร์ติน (2016). "แคสเปอร์: การติดตามอัตโนมัติของ dereferences ที่เป็นโมฆะกับการเริ่มต้นด้วยการติดตามเวรกรรม " วารสารระบบและซอฟต์แวร์ . 122 : 52–62. arXiv : 1502.02004 . ดอย : 10.1016/j.jss.2016.08.062 . ISSN 0164-1212 . S2CID 28161871 . เก็บถาวรจากต้นฉบับเมื่อ 2022-01-25 . สืบค้นเมื่อ2019-06-23 .  
  17. ^ " ตัวดีบั๊กฮาร์ดแวร์ SuperTrace Probe" www.ghs.com . เก็บถาวรจากต้นฉบับเมื่อ 2017-12-01 . สืบค้นเมื่อ2017-11-25 .
  18. ^ "ดีบักเกอร์และเครื่องมือติดตามแบบเรียลไทม์" . www.lauterbach.com . เก็บถาวรจากต้นฉบับเมื่อ 2022-01-25 . สืบค้นเมื่อ2020-06-05 .
  19. ^ ตันเครติ แมทธิว; Hossain, Mohammad Sajjad; Bagchi, ซอราภ; Raghunathan, วีเจย์ (2011). "Aveksha: แนวทางฮาร์ดแวร์-ซอฟต์แวร์สำหรับการติดตามและการทำโปรไฟล์ของระบบฝังตัวแบบไร้สายที่ไม่ล่วงล้ำ" การดำเนินการของการประชุม ACM ครั้งที่ 9 เกี่ยวกับระบบเซ็นเซอร์เครือข่ายแบบฝัง เซ็นซิส '11 นิวยอร์ก นิวยอร์ก สหรัฐอเมริกา: ACM: 288–301 ดอย : 10.1145/2070942.2070972 . ISBN 9781450307185. S2CID  14769602 .
  20. ^ ลิม โรมัน; เฟอร์รารี, เฟเดริโก; ซิมเมอร์ลิง, มาร์โค; วอลเซอร์, คริสตอฟ; ซอมเมอร์, ฟิลิปป์; Beutel, ม.ค. (2013). "FlockLab: เตียงทดสอบสำหรับการกระจาย การสืบค้นกลับแบบซิงโครไนซ์ และการทำโปรไฟล์ของระบบฝังตัวแบบไร้สาย" การดำเนินการของการประชุมนานาชาติครั้งที่ 12 ว่าด้วยการประมวลผลข้อมูลในเครือข่ายเซ็นเซอร์ IPSN '13. นิวยอร์ก นิวยอร์ก สหรัฐอเมริกา: ACM: 153–166 ดอย : 10.1145/2461381.2461402 . ISBN 9781450319591. S2CID  447045 .
  21. ^ ชีลด์ส, ไทเลอร์ (2008-12-02) "ซีรี่ส์ต่อต้านการดีบัก – ส่วนที่ 1" . เวราโค้ด เก็บถาวรจากต้นฉบับเมื่อ 2016-10-19 . สืบค้นเมื่อ2009-03-17 .
  22. a b "Software Protection through Anti-Debugging Michael N Gagnon, Stephen Taylor, Anup Ghosh" (PDF ) เก็บถาวรจากต้นฉบับ(PDF) เมื่อ 2011-10-01 สืบค้นเมื่อ2010-10-25 .
  23. ^ รอส เจ. แอนเดอร์สัน (2001-03-23). วิศวกรรมความปลอดภัย . หน้า 684. ISBN 0-471-38922-6.
  24. ^ "Microsoft Word สำหรับ DOS 1.15" . เก็บถาวรจากต้นฉบับเมื่อ 2013-05-14 . ดึงข้อมูลเมื่อ 2013-06-22 .

อ่านเพิ่มเติม

ลิงค์ภายนอก