เหตุใดการดีบักแบบย้อนกลับจึงไม่ค่อยได้ใช้ [ปิด]

gdb นำการสนับสนุนสำหรับการดีบักแบบย้อนกลับในปี 2009 (ด้วย gdb 7.0) ฉันไม่เคยได้ยินมาก่อนจนกระทั่งปี 2012 ตอนนี้ฉันพบว่ามีประโยชน์อย่างมากสำหรับปัญหาการดีบักบางประเภท ฉันหวังว่าฉันเคยได้ยินมาก่อน

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

คุณรู้จักชุมชนการเขียนโปรแกรมใด ๆ ที่มีการใช้การดีบักแบบย้อนกลับหรือไม่?

ข้อมูลพื้นฐาน:

• Stackoverflow: การดีบักแบบย้อนกลับทำงานอย่างไร
• gdb ใช้คำว่า "reverse debugging" แต่ผู้ขายรายอื่นใช้คำอื่น ๆ สำหรับเทคนิคที่เหมือนกันหรือคล้ายกัน:
  • Microsoft เรียกมันว่าIntelliTraceหรือ "Historical Debugging"
  • มี Java reverse debugger ที่เรียกว่าOmniscient Debuggerแม้ว่ามันอาจจะไม่ทำงานใน Java 6 อีกต่อไป
  • มีตัวแก้ไขการย้อนกลับ Java อื่น ๆ
  • ดีบักเกอร์ของ OCaml (ocamldebug) เรียกมันว่าการเดินทางข้ามเวลา

สำหรับการทำงานในโหมดดีบักที่มีการบันทึกนั้นมีราคาแพงมากเมื่อเทียบกับโหมด debug ปกติ มันยังใช้หน่วยความจำมากขึ้น

ง่ายกว่าที่จะลดความละเอียดจากระดับบรรทัดเป็นระดับการเรียกใช้ฟังก์ชัน ตัวอย่างเช่นดีบักเกอร์มาตรฐานใน eclipse ช่วยให้คุณ "ปล่อยไปที่เฟรม" ซึ่งเป็นหลักกระโดดกลับไปที่จุดเริ่มต้นของฟังก์ชั่นที่มีการรีเซ็ตพารามิเตอร์ทั้งหมด (ไม่มีอะไรทำในกองจะถูกเปลี่ยนกลับและfinallyบล็อกจะไม่ดำเนินการ ดังนั้นจึงไม่ใช่ตัวแก้จุดบกพร่องย้อนกลับที่แท้จริงโปรดใช้ความระมัดระวัง

โปรดทราบว่านี่เป็นเวลาหลายปีแล้วและทำงานร่วมกับการเปลี่ยนรหัสร้อน

ดังกล่าวแล้วประสิทธิภาพเป็นกุญแจสำคัญเช่นกับการดีบักแบบย้อนกลับได้ของ gdb การทำงานบางอย่างเช่น gzip เห็นการชะลอตัวของ 50,000 เท่าเมื่อเทียบกับการทำงานแบบดั้งเดิม อย่างไรก็ตามมีตัวเลือกเชิงพาณิชย์: ฉันทำงานกับ Undo undo.ioและผลิตภัณฑ์ UndoDB ของเราทำเหมือนกัน แต่มีการชะลอตัวน้อยกว่า 2x มีตัวแก้จุดบกพร่องเชิงพาณิชย์อื่น ๆ

สำหรับภาพรวมของตัวเลือกเทคโนโลยีและผลิตภัณฑ์ให้ดูชุดของโพสต์บล็อกที่ฉันเขียนเกี่ยวกับปีที่แล้ว (และติดตามตั้งแต่):

• http://jakob.engbloms.se/archives/1547 - เทคโนโลยี
• http://jakob.engbloms.se/archives/1554 - การวิจัย
• http://jakob.engbloms.se/archives/1564 - ผลิตภัณฑ์
• http://jakob.engbloms.se/archives/1768 - อัปเดตจากโพสต์ก่อนหน้า

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

และความจริงที่ว่า "ค่าเริ่มต้นราคาถูก" ของ gdb นั้นเกือบจะช้าอย่างผิดปกติและมีปัญหาด้านเสถียรภาพเล็กน้อยสำหรับทุกสิ่ง แต่เป็นระบบเป้าหมายที่พบบ่อยที่สุด

จากประสบการณ์ของฉันในฐานะวิศวกรฝ่ายขายสำหรับดีบัก TotalView ผู้คนรู้ว่ามันมีอยู่ แต่พวกเขาไม่คิดว่ามันจะทำงานได้โดยไม่คำนึงถึงการชะลอตัว (ยอมรับหรือไม่)

มหาวิทยาลัยเคมบริดจ์เมื่อเร็ว ๆ นี้ได้สำรวจสิทธิ"ล้มเหลวที่จะนำมาใช้ย้อนกลับแก้จุดบกพร่องค่าใช้จ่ายในเศรษฐกิจโลก $ 41 พันล้านปี"

และกลับมาที่ GDB ฉันได้ยินมาบ่อยครั้งมากว่าการชะลอตัวทำให้แอพพลิเคชั่น "ชีวิตจริง" ใช้งานไม่ได้

ฉันชอบที่จะได้รับการตอบกลับจากผู้คนจำนวนมากโดยใช้การดีบักแบบย้อนกลับในแอปพลิเคชันอื่น ๆ ที่ไม่ใช่ "Hello world!"

ฉันคิดว่ามันเป็นสิ่งสำคัญที่จะขยายเพิ่มเติมเล็กน้อยเกี่ยวกับการแก้ไขจุดบกพร่อง "ย้อนกลับ" หรือ "ประวัติศาสตร์" นี้ ฉันคิดว่าการเข้าใจระบบและพฤติกรรมที่ซับซ้อนในการเล่น "เหตุการณ์" ใหม่ซึ่งทำให้รัฐชัดเจนเป็นสิ่งสำคัญอย่างยิ่ง

สิ่งที่ฉันต้องการแสดงคือคุณไม่ได้อยู่คนเดียวในการสงสัยว่าทำไมเทคนิคนี้จึงไม่ค่อยมีการนำมาใช้ในวันนี้

ดังนั้นเราขอเน้นแนวคิดที่สำคัญสองประการที่นี่:

1. เพื่อให้เข้าใจถึงระบบการเขียนโปรแกรมจะเป็นประโยชน์ในการทำให้สถานะชัดเจน

2. เพื่อให้เข้าใจระบบการเขียนโปรแกรมซ้ำลำดับของรัฐ (เหตุการณ์) สามารถช่วยได้มาก

ต่อไปนี้เป็นแหล่งข้อมูลบางส่วนที่จัดการปัญหาและเสนอหรือแก้ไขปัญหาที่เกิดขึ้น (จัดการกับสถานะในระบบที่ซับซ้อน):

- ออกจากบิต tar กระดาษ: http://shaffner.us/cs/papers/tarpit.pdf แนวคิดหลัก: หลีกเลี่ยงแยกหรือทำให้รัฐชัดเจน

-CQRS http://www.cqrs.nu/ นี่คือการรวมกันของสองแนวคิด: Command Query Segregation และ Event Sourcing มีการนำไปใช้งานที่แตกต่างกัน (Java, C #, Scala) การเล่นซ้ำของ Tate sequences และการพัฒนารูปแบบโดเมนเป็นส่วนสำคัญที่นี่

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

ดังนั้นคุณอาจพูดได้ดีและดี แต่ใครใช้ CQRS และ FRP จริง ๆ ฉันจะพูด (IMO เพราะฉันไม่มีตัวเลขที่เป็นรูปธรรม) จริง ๆ แล้วมี บริษัท จำนวนมากที่พวกเขาไม่รู้จักงานที่พวกเขามีคำศัพท์นี้ บางทีคุณอาจจะลองไปฟังดูบ้างจากสถานประกอบการที่ใช้ CQRS แต่ก็มีเรื่องราวความสำเร็จอยู่แล้ว FRP ก็เพิ่มขึ้นอย่างช้าๆเช่นฉันจะให้ Netflix: http://techblog.netflix.com/2013/02/rxjava-netflix-api.html ซึ่งเพิ่งเปิดตัวการใช้งานของ RX ซึ่งจริงๆแล้วใช้. NET (แต่มี การใช้งานจาวาสคริปต์ด้วย) ดังนั้นผู้คนจึงใช้เทคนิคเหล่านี้ในวันนี้อยู่แล้วในขนาดใหญ่เพื่อทำความเข้าใจกับระบบที่ซับซ้อนและทำให้พวกเขาดียิ่งขึ้น นั่นคือเหตุผลที่พวกเขาใช้เทคนิคการดีบักแบบย้อนกลับ