การแก้ไขปัญหาการรั่วไหลของหน่วยความจำมีความสำคัญอย่างไร

ฉันพบโดย Valgring ว่าบางโปรแกรม GTK + รั่วหน่วยความจำ การแก้ไขรอยรั่วนั้นสำคัญขนาดไหน? ฉันหมายถึงบ่อยครั้งที่โปรแกรมเหล่านั้นทำงานได้ดีมาก แต่ในทางกลับกันเราไม่สามารถมั่นใจได้ว่าหากต้องการคัดลอกส่วนหนึ่งของรหัสที่รั่วไปยังโปรแกรมอื่น และฉันไม่แน่ใจว่าแนวคิดของ GTK + - โปรแกรมทำงานเร็วหรือไม่ดังนั้นจึงมีการรั่วไหล

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

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

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

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

อย่างไรก็ตามการวิ่งระยะสั้นนั้นสัมพันธ์กันการรั่วไหลสามารถหมุนออกจากการควบคุมในไม่กี่ชั่วโมงหรือซ้อนกันเป็นสัปดาห์โดยไม่มีใครสังเกต

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

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

ในความเห็นที่เป็นที่ยอมรับของฉันในเรื่องนี้ไม่มีข้อแก้ตัวสำหรับการรั่วไหลของร่างกายอย่างน้อยในห้องสมุดใด ๆ ที่มีจุดมุ่งหมายที่จะนำไปใช้อย่างกว้างขวาง ดังนั้นฉันจึงพยายามที่จะบั๊กนักพัฒนา GTK + จนกว่าพวกเขาจะแก้ไขด้วยตนเอง

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

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

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

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

อย่างไรก็ตามอย่างน้อยที่สุดฉันก็จะกรองการรั่วไหลใน valgrind อย่างน้อยพวกเขาก็จะไม่ยุ่งกับความสามารถของทีมในการมองเห็นตัวคุณเอง

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