C Academy · บทเรียน

เหตุใดจึงใช้ Valgrind

ตรวจจับข้อผิดพลาดด้านหน่วยความจำ

เหตุใดจึงใช้ Valgrind เป็นบทเรียน C Academy ฟรีบน CoddyKit นี่คือบทเรียนที่ 1 จากทั้งหมด 4 บทเรียน คุณสามารถอ่านบทเรียนทั้งหมดด้านล่างฟรี — จากนั้นลองปฏิบัติด้วยตัวคุณเองในเบราว์เซอร์พร้อมตัวแก้ไขโค้ดในตัวและติวเตอร์ AI ตลอด 24/7 บทเรียนนี้เป็นส่วนหนึ่งของเส้นทางการเรียน C Academy และความก้าวหน้าของคุณจะซิงค์ข้ามเว็บและแอป CoddyKit คอร์ส C Academy มีบทเรียนทั้งหมด 4 บทเรียน

Valgrind คืออะไร

Valgrind คือเฟรมเวิร์กสำหรับแทรกเครื่องมือที่ทำงานโดยให้โปรแกรมของคุณทำงานภายใน CPU จำลอง และตรวจสอบการดำเนินการกับหน่วยความจำทุกครั้ง

เครื่องมือที่มีผู้ใช้มากที่สุดคือ memcheck ซึ่งตรวจจับข้อผิดพลาดที่ทำให้โปรแกรม C ล้มเหลวหลังจากเกิดความผิดพลาดจริงไปแล้วหลายชั่วโมง

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

เหตุใดภาษา C จึงต้องใช้สิ่งนี้

C ไม่มีตัวเก็บขยะและไม่มีการตรวจสอบขอบเขต คอมไพเลอร์จึงเชื่อใจคุณอย่างเต็มที่

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

Valgrind มอบ ตาข่ายนิรภัยที่ภาษาไม่ยอมจัดเตรียมให้ แก่คุณ

โปรแกรมที่ทำให้หน่วยความจำรั่ว

โปรแกรมนี้จัดสรรหน่วยความจำแต่ไม่เคยคืนหน่วยความจำ โปรแกรมคอมไพล์และทำงานได้โดยไม่มีการแจ้งเตือน

บล็อกที่จัดสรรด้วย malloc จะสูญหายทันทีที่ main คืนค่า สำหรับเซิร์ฟเวอร์ที่ทำงานเป็นเวลานาน บล็อกลักษณะนี้หลายพันบล็อกจะใช้ RAM จนหมด

#include <stdlib.h>
#include <stdio.h>

int main(void) {
    int *data = malloc(100 * sizeof(int));
    data[0] = 42;
    printf("%d\n", data[0]);
    return 0; /* forgot free(data) */
}

สิ่งที่คอมไพเลอร์มองไม่เห็น

หากเรียกใช้โปรแกรมนั้นด้วย gcc -Wall -Wextra คุณจะได้รับ คำเตือนเป็นศูนย์

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

นี่คือช่องว่างที่ Valgrind เข้ามาเติมเต็ม

การแทรกเครื่องมือทำงานอย่างไร

Valgrind ไม่ต้องใช้ซอร์สโค้ดหรือแฟล็กพิเศษตอนคอมไพล์ แต่ทำงานกับไบนารีที่คอมไพล์แล้ว

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

การเรียกใช้

คำสั่งพื้นฐานเพียงเติมคำนำหน้าให้กับคำสั่งปกติของคุณ

แฟล็ก --leak-check=full จะขอรายละเอียดแยกตามหน่วยความจำรั่วแต่ละรายการ พร้อมเส้นทางการเรียกฟังก์ชัน

valgrind --leak-check=full ./myprogram arg1 arg2

คอมไพล์เพื่อให้รายงานมีข้อมูลครบถ้วน

Valgrind เรียกใช้ไบนารีใดก็ได้ แต่รายงานจะมีประโยชน์มากขึ้นเมื่อมีสัญลักษณ์แก้จุดบกพร่อง

คอมไพล์ด้วย -g เพื่อให้เส้นทางการเรียกแสดงชื่อไฟล์และหมายเลขบรรทัดแทนที่อยู่ดิบ

-g เพิ่มข้อมูลแก้จุดบกพร่อง
-O0 ป้องกันการจัดเรียงใหม่โดยตัวปรับให้เหมาะสม ซึ่งอาจทำให้เส้นทางการเรียกสับสน

gcc -g -O0 -o myprogram myprogram.c

ต้นทุนที่ต้องแลก

การแทรกเครื่องมือไม่ได้ไม่มีต้นทุน โปรแกรมที่ทำงานภายใต้ memcheck จะทำงานช้าลงประมาณ 10 ถึง 50 เท่า และใช้หน่วยความจำมากขึ้น

เรื่องนี้ไม่เป็นปัญหาสำหรับการทดสอบและการแก้จุดบกพร่อง แต่คุณไม่ควรส่งไบนารีที่ทำงานภายใต้ Valgrind ไปใช้งานจริง เพราะ Valgrind เป็นเครื่องมือสำหรับการพัฒนา

ชุดเครื่องมือ

Valgrind ไม่ได้มีแค่ memcheck เครื่องมืออื่น ๆ ใช้แกนกลางเดียวกัน:

memcheck — ตรวจจับข้อผิดพลาดของหน่วยความจำและหน่วยความจำรั่ว (ค่าเริ่มต้น)
cachegrind — วิเคราะห์การใช้แคชและการแยกแขนง
callgrind — วิเคราะห์กราฟการเรียกฟังก์ชัน
helgrind — ตรวจจับการแข่งขันระหว่างเธรด
massif — วิเคราะห์การใช้ HEAP ตามช่วงเวลา

เมื่อใดควรหยิบมาใช้

ใช้ Valgrind เมื่อพบอาการเหล่านี้:

โปรแกรมล้มเหลวอย่างลึกลับ และตำแหน่งความผิดพลาดเปลี่ยนเมื่อเพิ่ม printf
การใช้หน่วยความจำเพิ่มขึ้นไม่หยุด
ค่าแปลกปลอมเปลี่ยนไปในแต่ละครั้งที่ทำงาน
โปรแกรมล้มเหลวเฉพาะกับอินพุตหรือแพลตฟอร์มบางชนิด

อาการเหล่านี้เป็นลักษณะบ่งชี้แบบคลาสสิกของ พฤติกรรมที่ไม่ได้กำหนด จากข้อผิดพลาดเกี่ยวกับหน่วยความจำ

ข้อจำกัดที่ควรรู้

Valgrind มีประสิทธิภาพสูง แต่ไม่ได้รู้เห็นทุกอย่าง:

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

ใช้ร่วมกับเครื่องมือตรวจสอบและการทดสอบเพื่อให้ครอบคลุมอย่างสมบูรณ์

ตรวจสอบความเข้าใจ

ทดสอบความเข้าใจเกี่ยวกับสิ่งที่ Valgrind ต้องใช้

สรุปทบทวน

ตอนนี้คุณรู้แล้วว่า Valgrind คืออะไรและเหตุใด C จึงต้องใช้:

C ไม่มีความปลอดภัยของหน่วยความจำโดยอัตโนมัติ ข้อผิดพลาดขณะทำงานจึงอาจผ่านคอมไพเลอร์ไปได้
Valgrind แทรกเครื่องมือในไบนารีเพื่อติดตามการเข้าถึงหน่วยความจำทุกครั้ง
memcheck ตรวจจับหน่วยความจำรั่ว การเข้าถึงที่ไม่ถูกต้อง และการอ่านค่าที่ยังไม่ได้กำหนด
คอมไพล์ด้วย -g -O0 เพื่อให้รายงานอ่านได้ชัดเจน แต่ต้องคาดว่าจะทำงานช้าลงมาก

ถัดไป คุณจะตรวจจับหน่วยความจำรั่วจริงด้วย memcheck

คำถามที่พบบ่อย

บทเรียน “เหตุใดจึงใช้ Valgrind” ฟรีหรือไม่

ใช่ — ข้อความเต็มของ “เหตุใดจึงใช้ Valgrind” ฟรีให้อ่านที่นี่บนเว็บ เพื่อปฏิบัติแบบโต้ตอบ (ตัวแก้ไขโค้ดในตัวและติวเตอร์ AI ตลอด 24/7) และปลดล็อคส่วนที่เหลือของคอร์ส C Academy ให้อัปเกรดเป็น CoddyKit PRO คอร์ส C Academy มีบทเรียนทั้งหมด 4 บทเรียน

คุณจะเรียนรู้อะไรในบทเรียน “เหตุใดจึงใช้ Valgrind”

ตรวจจับข้อผิดพลาดด้านหน่วยความจำ คุณปฏิบัติ C Academy ด้วยโค้ดที่ใช้งานได้จริงที่คุณเรียกใช้โดยตรงในเบราว์เซอร์ และติวเตอร์ AI ตลอด 24/7 ตอบคำถามของคุณขณะที่คุณไปผ่านบทเรียน

คุณต้องมีประสบการณ์ก่อนที่จะเริ่มเรียน C Academy หรือไม่

ไม่จำเป็นต้องมีประสบการณ์มาก่อน C Academy บน CoddyKit ออกแบบมาสำหรับผู้เริ่มต้นไปจนถึงผู้เรียนขั้นสูง คุณสามารถเริ่มต้นที่นี่หรือเริ่มจากตัวแรกและเรียนด้วยความเร็วของคุณเอง นี่คือบทเรียนที่ 1 จากทั้งหมด 4 บทเรียน

บทเรียน “เหตุใดจึงใช้ Valgrind” ใช้เวลานานแค่ไหน

บทเรียน CoddyKit ส่วนใหญ่ใช้เวลาประมาณ 5–10 นาที แต่ละบทเรียนจึงสั้นและเป็นแบบโต้ตอบ คุณสามารถก้าวหน้าอย่างต่อเนื่องและกลับมาเรียนต่อจากตรงที่เพิ่งหยุดบนเว็บและแอปได้เลย

ฉันเขียนและรันโค้ดในบทเรียน C Academy นี้ได้ไหม

ได้ บทเรียน C Academy ทุกบทมีตัวแก้ไขโค้ดในตัว คุณจึงเขียนและรันโค้ดจริงได้เลยในเบราว์เซอร์ และได้รับข้อเสนอแนะจาก AI ในทันที — ไม่ต้องติดตั้งในเครื่องของคุณ

บทเรียนทั้งหมดในหลักสูตรนี้

← กลับไปที่ C Academy