ডিবাগিং — gdb, sanitizer আর Valgrind দিয়ে বাগ খোঁজা

১ · Bug কোথায় থাকে — ডিবাগিং একটি বৈজ্ঞানিক পদ্ধতি

পর্ব ৩০-এ আমরা শিখেছি, প্রোগ্রামের বাইরের পৃথিবী থেকে আসা ভুল — ফাইল নেই, মেমরি ফুরিয়েছে — কীভাবে সামলাতে হয়। কিন্তু আরেক জাতের ভুল আছে, যার জন্য কোনো if লেখা যায় না: আপনার নিজের কোডের ভুল। প্রোগ্রাম ভুল উত্তর দেয়, হঠাৎ ভেঙে পড়ে, বা দিনে দিনে মেমরি খেয়ে ফেলে। এই ভুলকে বলে bug, আর তাকে খুঁজে বের করে ঠিক করার কাজকে বলে debugging.

নতুন প্রোগ্রামাররা প্রায়ই এভাবে debug করেন: কোথাও একটা কিছু বদলান, আবার চালান, না হলে আরেকটা কিছু বদলান। কখনো কখনো ঠিকও হয়ে যায় — কিন্তু কেন ঠিক হলো, তা কেউ জানে না। এতে bug প্রায়ই মরে না, শুধু লুকিয়ে পড়ে। পেশাদার পদ্ধতি একদম আলাদা।

এই পদ্ধতিটি ছয়টি ধাপে চলে। নিচে একটি বাস্তব bug-এর ওপর পুরো চক্রটি প্রয়োগ করা হলো: পাঁচজন ছাত্রের নম্বরের গড় বের করার একটি প্রোগ্রাম, যা ভুল গড় দেখাচ্ছে। “পরে” চেপে এগোন:

ইনপুট : 72 85 90 67 81
হাতে হিসাব : (72+85+90+67+81) / 5 = 395 / 5 = 79.00
প্রোগ্রাম  : Average: 64.00        (পাঁচবার চালালাম, পাঁচবারই 64.00)

[dbg] i=1 mark=85 sum=85
[dbg] i=2 mark=90 sum=175
[dbg] i=3 mark=67 sum=242
[dbg] i=4 mark=81 sum=323
[dbg] sum=323 used=4 avg=64.00   ← i=0 নেই! আর 323/5 = 64.6, অথচ 64.00

অনুমান ক : লুপ i = 1 থেকে শুরু — প্রথম নম্বর 72 বাদ পড়ছে
অনুমান খ : sum / n দুটোই int — integer division, দশমিক কেটে যাচ্ছে
          (ভুল ধারণা ছিল: "double-এ রাখলেই ভাগফল দশমিক হবে")

পরীক্ষা ১: i = 0 করলে ভবিষ্যদ্বাণী sum = 395      → এলো 395  অনুমান ক সত্য
          কিন্তু 395/5 = 79 পুরো সংখ্যা — খ লুকিয়ে গেল!
পরীক্ষা ২: ইনপুট {1, 2}, ভবিষ্যদ্বাণী খ সত্য হলে 1.00 → এলো 1.00 খ-ও সত্য

for (int i = 0; i < n; i++)
double avg = (double)sum / n;
ফল: Average: 79.00, আর {1, 2}-এ 1.50

assert(used == n);                         /* সব নম্বর গোনা হয়েছে */
test: average({1, 2}) == 1.50              /* integer division ফিরলেই ধরা পড়বে */
test: average({72, 85, 90, 67, 81}) == 79.00

চক্রটিকে গতি দেওয়ার চারটি অভ্যাস

• Error message পুরোটা পড়ুন — প্রথম লাইন থেকে। Compiler বা sanitizer প্রায়ই সঠিক ফাইল, লাইন আর কারণ বলে দেয়। প্রথম error-টিই সাধারণত আসল; পরের বিশটি প্রায়ই তারই প্রতিধ্বনি।
• রাবার হাঁসকে বোঝান। Rubber duck debugging নামটি এসেছে “The Pragmatic Programmer” (১৯৯৯) বইয়ের একটি গল্প থেকে: একজন প্রোগ্রামার টেবিলে রাখা খেলনা হাঁসকে লাইন ধরে ধরে কোড বোঝাতেন। “এই লাইনে i শূন্য থেকে… না, এক থেকে শুরু হচ্ছে!” — জোরে বলতে গেলেই অনেক ভুল ধারণা নিজের কানে ধরা পড়ে।
• Bug-কে ছোট করুন। ১০,০০০ লাইনের প্রোগ্রামে bug খোঁজা কঠিন। যে অংশ বাদ দিলেও bug থাকে, সেটি বাদ দিন — যতক্ষণ না ১৫–২০ লাইনের একটি minimal reproducible example পান। অনেক সময় ছাঁটতে ছাঁটতেই কারণ চোখে পড়ে যায়, আর কাউকে সাহায্যের জন্য দেখাতেও এটিই লাগে।
• “কাল চলত, আজ চলে না”? Binary search করুন। পর্ব ৪১-এ যে binary search বিস্তারিত দেখবেন, তার মূল চিন্তা সহজ: প্রতিবার খোঁজার জায়গা অর্ধেক করা। Git-এর git bisect commit-এর ইতিহাসে ঠিক সেটাই করে — ১,০০০টি commit-এর মধ্যে মাত্র ১০টির মতো পরীক্ষায় দেখিয়ে দেয় কোন commit প্রথম bug এনেছিল।

২ · Bug-এর জাত চেনা — কোন ভুলে কোন যন্ত্র

ডাক্তার জ্বর দেখলেই একই ওষুধ দেন না — আগে রোগ চেনেন। Bug-ও কয়েক জাতের, আর প্রতিটির জন্য আলাদা যন্ত্র। জাত চেনা গেলে অর্ধেক কাজ শেষ:

খেয়াল করুন, তালিকার ওপরের দিকে bug যত, ধরা তত সহজ — compiler নিজেই লাইন দেখিয়ে দেয়। নিচের দিকে যত নামবেন, bug তত চুপচাপ। এজন্য পেশাদারদের একটি কৌশল হলো bug-কে ওপরের দিকে ঠেলে দেওয়া: ভুল উত্তরকে assert দিয়ে crash-এ বদলে দেওয়া, চুপচাপ মেমরি-ভুলকে sanitizer দিয়ে স্পষ্ট রিপোর্টে বদলে দেওয়া। জোরে ভেঙে পড়া bug চুপচাপ ভুল উত্তর দেওয়া bug-এর চেয়ে অনেক ভালো।

৩ · প্রথম debugger — compiler-এর warning

সবচেয়ে সস্তা debugger আপনার হাতেই আছে, আর সে কাজ করে প্রোগ্রাম চালানোর আগেই। GCC-কে -Wall -Wextra দিলে সে কোড পড়ে সন্দেহজনক জিনিসগুলো জানায়। প্রতিটি warning মানে “এটা বৈধ C, কিন্তু আপনি সম্ভবত এটা বোঝাতে চাননি।” নিচের নমুনা দেখুন — প্রতিটি warning একটি সত্যিকারের bug:

$ gcc -Wall -Wextra avg.c -o avg
avg.c: In function 'main':
avg.c:9:23: warning: comparison of integer expressions of different signedness: 'int' and 'size_t' {aka 'long unsigned int'} [-Wsign-compare]
avg.c:11:12: warning: suggest parentheses around assignment used as truth value [-Wparentheses]
avg.c:10:9: warning: 'sum' is used uninitialized [-Wuninitialized]

• প্রথমটি: int i-কে size_t-এর সাথে তুলনা। i ঋণাত্মক হলে তুলনার আগে সেটি বিশাল unsigned সংখ্যা হয়ে যায় (পর্ব ০৮)।
• দ্বিতীয়টি: if (mark = 100) — তুলনা নয়, assignment! শর্ত সবসময় সত্য।
• তৃতীয়টি: int sum; লিখে শূন্য দেওয়া হয়নি, অথচ লুপে sum += … — যোগফল শুরু হবে আবর্জনা মান থেকে (পর্ব ০৬)। এই warning-টি GCC কোড বিশ্লেষণের পরের ধাপে দেয়, তাই তালিকায় শেষে আসে।

এই warning-গুলো উপেক্ষা করে gdb নিয়ে বসলে আধঘণ্টা নষ্ট হতো; compiler এক সেকেন্ডে বলে দিল। তাই নিয়ম: warning-মুক্ত না হওয়া পর্যন্ত debugger খুলবেন না।

-Werror — warning জমতে না দেওয়া

একটি প্রজেক্টে ২০০টি পুরোনো warning জমে থাকলে নতুন, জরুরি warning-টি তাদের ভিড়ে হারিয়ে যায়। -Werror flag প্রতিটি warning-কে error বানিয়ে দেয় — warning থাকলে প্রোগ্রাম তৈরিই হয় না। অনেক দল তাদের CI-তে -Wall -Wextra -Werror দিয়ে build করে। তবে একটি বাস্তব সতর্কতা: নতুন সংস্করণের compiler নতুন warning যোগ করে, তাই যাঁরা আপনার source code ডাউনলোড করে নিজের compiler-এ build করবেন, তাঁদের জন্য -Werror চাপিয়ে দিলে build অকারণে ভাঙতে পারে। সাধারণ চর্চা: নিজের দলের build ও CI-তে -Werror, প্রকাশিত build script-এ নয়।

Static analysis — না চালিয়েই কোড পরীক্ষা

Warning-এর পরের স্তর হলো static analysis: টুল প্রোগ্রাম না চালিয়ে কোডের সম্ভাব্য সব পথ খুঁজে দেখে, কোনো পথে NULL pointer ব্যবহার বা free না করা মেমরি আছে কি না। তিনটি পরিচিত নাম:

Static analysis কিছু মিথ্যা alarm দেবে, আবার কিছু আসল bug বাদও দেবে — কারণ সব পথ নিখুঁতভাবে বিশ্লেষণ করা তাত্ত্বিকভাবেই অসম্ভব। তবুও এটি সস্তা পাহারা: একবার সেটআপ করলে প্রতিটি commit-এ বিনা পরিশ্রমে চলে।

৪ · printf আর assert — ঠিকভাবে করলে খুব শক্তিশালী

“আসল প্রোগ্রামাররা debugger ব্যবহার করেন, printf নয়” — এই কথাটি অর্ধেক সত্য। printf debugging সব জায়গায় চলে: দূরের server-এ, ছোট microcontroller-এ, যেখানে debugger বসানো যায় না। অনেক অভিজ্ঞ প্রোগ্রামার আজও প্রথমে এটিই করেন। শুধু চারটি নিয়ম মানতে হয়:

1. stdout নয়, stderr-এ লিখুন। পর্ব ১০-এ দেখেছেন, stdout সাধারণত buffer করা থাকে — লেখা জমে থাকে, পরে একসাথে বেরোয়। প্রোগ্রাম crash করলে জমে থাকা লেখা কখনো বেরোয়ই না, আর আপনি ভুল জায়গায় crash খুঁজবেন। stderr ডিফল্টে buffer করা থাকে না, তাই লেখা সাথে সাথে বেরোয়। তাছাড়া আসল আউটপুটের সাথে debug লেখা মেশে না।
2. stdout ব্যবহার করতেই হলে flush করুন। fflush(stdout) জমে থাকা লেখা তখনই পাঠিয়ে দেয়।
3. প্রতিটি লেখায় চিহ্ন দিন। শুধু 85 ছাপলে পরে বোঝা যায় না কোনটি কী। [dbg] i=1 mark=85 sum=85 — কোন ভ্যারিয়েবল, কোন মান, সব স্পষ্ট।
4. একটি macro-য় রাখুন। পর্ব ২৭-এর macro দিয়ে DBG(...) বানান। এখানে ... আর __VA_ARGS__ macro-কে পর্ব ২৫-এর variadic ফাংশনের মতো যতগুলো খুশি argument নিতে দেয়। এতে পরে এক জায়গা থেকে সব debug লেখা বন্ধ করা যায়, আর কোথায় কোথায় আছে খুঁজে মুছতে সহজ হয়।

assert — নিজের ধারণাকে চালানো যায় এমন শর্তে বদলে দেওয়া

পর্ব ৩০-এ assert দেখেছেন: “আমার কোড ঠিক থাকলে এটা সবসময় সত্য।” ডিবাগিংয়ের দৃষ্টিতে assert-এর আসল মূল্য এখানে — অংশ ১-এ বলেছিলাম, bug মানে একটি ভুল ধারণা। assert সেই ধারণাকে মাথা থেকে কোডে নামিয়ে আনে, আর ধারণা ভাঙলেই প্রোগ্রাম চিৎকার করে ওঠে — ঠিক ভাঙার জায়গায়, শত লাইন পরে নয়।

নিচের প্রোগ্রামটি অংশ ১-এর সেই ভুল গড়ের প্রোগ্রাম, debug print আর একটি assert-সহ। চালিয়ে দেখুন কী হয় — এখানে assert ইচ্ছা করেই ব্যর্থ হবে, কারণ ঠিক সেটাই আমরা দেখতে চাই:

#include <stdio.h>
#include <assert.h>
#define DBG(...) fprintf(stderr, "[dbg] " __VA_ARGS__)

int main(void) {
    int marks[] = {72, 85, 90, 67, 81};
    int n = 5, sum = 0, used = 0;
    for (int i = 1; i < n; i++) {          /* BUG 1 */
        sum += marks[i];
        used++;
        DBG("i=%d mark=%d sum=%d\n", i, marks[i], sum);
    }
    double avg = sum / n;                    /* BUG 2 */
    DBG("sum=%d used=%d avg=%.2f\n", sum, used, avg);
    assert(used == n && "every mark must be counted");
    printf("Average: %.2f\n", avg);
    return 0;
}

এবার ঠিক করা সংস্করণ। দুটি bug-এর সমাধান ছাড়াও তিনটি জিনিস বদলেছে: গড়ের কাজটি একটি আলাদা ফাংশনে গেছে, ফাংশনের শুরুতে assert তার পূর্বশর্ত পাহারা দিচ্ছে, আর শেষে একটি “জানা উত্তর” যাচাই — 395 ÷ 5 = 79:

#include <stdio.h>
#include <assert.h>
#define DBG(...) fprintf(stderr, "[dbg] " __VA_ARGS__)

static double average(const int *a, int n) {
    assert(a != NULL && n > 0);              /* precondition */
    int sum = 0, used = 0;
    for (int i = 0; i < n; i++) { sum += a[i]; used++; }
    assert(used == n);
    return (double)sum / n;                  /* no integer division */
}

int main(void) {
    int marks[] = {72, 85, 90, 67, 81};
    int n = (int)(sizeof marks / sizeof marks[0]);
    double avg = average(marks, n);
    DBG("n=%d avg=%.2f\n", n, avg);
    assert(avg > 78.99 && avg < 79.01);       /* known answer */
    printf("Average: %.2f\n", avg);
    return 0;
}

৫ · gdb — চলন্ত প্রোগ্রামকে থামিয়ে প্রশ্ন করা

printf-এর একটি সীমা আছে: কী ছাপবেন, তা আগে থেকে ঠিক করতে হয়। নতুন প্রশ্ন মাথায় এলে কোড বদলে আবার compile করতে হয়। Debugger-এ এই ঝামেলা নেই — প্রোগ্রাম যেকোনো জায়গায় থামিয়ে যেকোনো প্রশ্ন করা যায়। পর্ব ০৩-এ debugger-এর ধারণা দেখেছিলেন; এবার আসল যন্ত্র, GDB — GNU Debugger, যা Richard Stallman ১৯৮৬ সালে লেখা শুরু করেছিলেন এবং আজও Linux-এ C ডিবাগিংয়ের মূল হাতিয়ার।

প্রথম শর্ত: -g -O0

সাধারণ compile-এ প্রোগ্রামের ভেতরে লাইন নম্বর বা ভ্যারিয়েবলের নাম থাকে না — শুধু machine code. -g দিলে compiler ভেতরে debug symbols রেখে দেয়: কোন instruction কোন লাইনের, কোন ভ্যারিয়েবল মেমরির কোথায়। আর -O0 optimization বন্ধ রাখে। optimization চালু থাকলে compiler লাইনের ক্রম বদলায়, ভ্যারিয়েবল register-এ লুকিয়ে ফেলে বা মুছেই দেয় — gdb তখন বলে <optimized out>, আর next চাপলে লাইন এলোমেলো লাফায়।

$ gcc -g -O0 -Wall -Wextra maxmark.c -o maxmark     # debug build
$ gdb -q ./maxmark                                  # -q: শুরুর লম্বা পরিচিতি বাদ

যে ১০টি কমান্ড দিয়ে প্রায় সব কাজ চলে (প্রতিটির ছোট রূপও আছে — বন্ধনীতে):

next আর step-এর পার্থক্যই stepping-এর মূল কথা: যে ফাংশনকে আপনি বিশ্বাস করেন (printf), তার ওপর দিয়ে next; যাকে সন্দেহ করেন, তার ভেতরে step.

এবার একটি আসল সেশন। find_max পাঁচটি নম্বরের মধ্যে সর্বোচ্চটি দেওয়ার কথা — {95, 70, 88, 60, 79}-এ উত্তর হওয়া উচিত 95, কিন্তু প্রোগ্রাম বলছে Highest: 88. ডান দিকে gdb-র নমুনা আউটপুট — আপনার মেশিনে প্রায় এমনই দেখাবে, শুধু ঠিকানাগুলো আলাদা হবে:

3int find_max(const int *a, int n) {4    int max = 0;5    for (int i = 1; i < n; i++)6        if (a[i] > max)7            max = a[i];8    return max;9}

৬ · Crash-এর পরে — backtrace, frame আর core dump

সবচেয়ে ভয়ের বার্তা দিয়ে শুরু করি: Segmentation fault (core dumped). কোনো লাইন নম্বর নেই, কোনো কারণ নেই। পর্ব ১৭-তে দেখেছেন, segmentation fault মানে প্রোগ্রাম এমন মেমরিতে হাত দিয়েছে যা তার নয়, আর OS তাকে বন্ধ করে দিয়েছে। gdb-র ভেতরে একই প্রোগ্রাম চালালে ছবিটা পুরো বদলে যায়:

$ gdb -q ./roster
(gdb) run
Starting program: /home/rafi/roster

Program received signal SIGSEGV, Segmentation fault.
0x0000555555555175 in is_pass (s=0x0) at roster.c:7
7           return s->mark >= 40;
(gdb) backtrace
#0  0x0000555555555175 in is_pass (s=0x0) at roster.c:7
#1  0x00005555555551f2 in main () at roster.c:16
(gdb) frame 1
#1  0x00005555555551f2 in main () at roster.c:16
16          printf("pass=%d\n", is_pass(find(list, n, "Karim")));
(gdb) print find(list, n, "Karim")
$1 = (struct student *) 0x0

লাইন ধরে পড়ুন। SIGSEGV হলো segmentation fault-এর signal-এর নাম। প্রোগ্রাম থেমেছে is_pass ফাংশনে, লাইন ৭-এ, আর argument s=0x0 — অর্থাৎ NULL pointer-এর ->mark পড়তে গিয়ে crash. তারপর backtrace: #0 হলো যেখানে থেমেছে, #1 হলো যে তাকে ডেকেছে। পর্ব ১৩-এর call stack-এর প্রতিটি stack frame এখানে এক লাইন। frame 1 দিয়ে main-এর প্রেক্ষাপটে গিয়ে দেখা গেল, find "Karim"-কে খুঁজে পায়নি, NULL দিয়েছে — আর main সেটা যাচাই না করেই is_pass-কে দিয়েছে।

Core dump — crash-এর ছবি পরে দেখা

কিন্তু crash যদি gdb-র বাইরে হয়, বা রাত তিনটায় server-এ? তখন কাজে আসে core dump: crash-এর মুহূর্তে প্রোগ্রামের মেমরির একটি ছবি, যা ফাইলে লেখা হয়। “core dumped” কথাটির মানে এটাই — যদিও অনেক সিস্টেমে ডিফল্টে core ফাইল তৈরি বন্ধ থাকে:

$ ulimit -c unlimited        # এই shell-এ core ফাইলের আকারের সীমা তুলে দিন
$ ./roster
Segmentation fault (core dumped)
$ gdb -q ./roster core       # প্রোগ্রাম + core: crash-এর মুহূর্তে ফেরা
(gdb) bt                     # আগের মতোই backtrace, প্রোগ্রাম আবার না চালিয়েই

আধুনিক Linux distribution-এ core ফাইল প্রায়ই সরাসরি ফোল্ডারে আসে না — systemd-coredump বা Ubuntu-র apport সেটি নিজের জায়গায় জমা রাখে। systemd-ভিত্তিক সিস্টেমে coredumpctl list আর coredumpctl gdb দিয়ে খুঁজে খোলা যায়। মূল ধারণা একই: crash-এর প্রমাণ সংরক্ষণ, যাতে পরে ধীরে-সুস্থে তদন্ত করা যায়। Core ফাইল কাজে লাগাতে প্রোগ্রামটি -g-সহ build করা থাকতে হবে, অথবা debug symbol আলাদা ফাইলে রেখে দিতে হবে।

৭ · Sanitizer — প্রোগ্রামের ভেতরে বসানো পাহারাদার

এবার সবচেয়ে বিপজ্জনক জাতের bug: মেমরির ভুল। অ্যারের সীমা পেরিয়ে এক ঘর লেখা প্রায়ই সাথে সাথে crash করে না — হয়তো পাশের কোনো ভ্যারিয়েবল চুপচাপ নষ্ট হয়, আর লক্ষণ দেখা দেয় অনেক পরে, অন্য কোনো ফাংশনে। পর্ব ৪৬-এ দেখবেন, এগুলো undefined behavior — “আজ চলে, কাল চলে না।” gdb দিয়ে এমন bug খোঁজা খড়ের গাদায় সুঁই খোঁজা।

সমাধান হলো sanitizer: compiler প্রোগ্রামের প্রতিটি মেমরি-ব্যবহারের পাশে ছোট পাহারা-কোড বসিয়ে দেয়। প্রোগ্রাম চলার সময় ভুল হলেই সেই মুহূর্তে থেমে বিস্তারিত রিপোর্ট দেয়। GCC আর Clang দুটোতেই একটি flag-এ চালু হয়:

$ gcc -g -O1 -fsanitize=address,undefined -fno-omit-frame-pointer report.c -o report
$ ./report

ASan কীভাবে কাজ করে — shadow memory আর redzone

ASan প্রোগ্রামের প্রতি ৮ বাইট মেমরির জন্য ১ বাইটের একটি গোপন হিসাব রাখে, যার নাম shadow memory. সেখানে লেখা থাকে: এই ৮ বাইটের সবগুলো ছোঁয়া বৈধ (00), প্রথম কয়েকটি বৈধ (01–07), নাকি কোনোটিই নয় (fa, fd…)। আর প্রতিটি malloc-এর দুই পাশে ASan রাখে নিষিদ্ধ ফাঁকা জায়গা — redzone. প্রতিটি পড়া-লেখার আগে বসানো পাহারা-কোড shadow দেখে নেয়; redzone ছুঁলেই রিপোর্ট।

এবার একটি আসল রিপোর্ট পড়া যাক। প্রোগ্রামটি ৫টি int-এর (২০ বাইট) জায়গা নিয়ে লুপ চালিয়েছে i <= 5 পর্যন্ত — ছয়বার:

1  #include <stdlib.h>
2  int main(void) {
3      int *marks = malloc(5 * sizeof(int));     /* 20 bytes */
4      for (int i = 0; i <= 5; i++)              /* BUG: should be i < 5 */
5          marks[i] = 50 + i;
6      free(marks);
7      return 0;
8  }

ASan-সহ চালালে প্রোগ্রাম লাইন ৫-এ, ষষ্ঠ লেখার মুহূর্তে থেমে যায়। রিপোর্টটি লম্বা আর ভীতিকর দেখায় — কিন্তু ওপর থেকে নিচে পড়লে এটি একটি সাজানো গল্প। নমুনা আউটপুট (আপনার মেশিনে এমনই দেখাবে, ঠিকানা ও process নম্বর আলাদা হবে):

==8812==ERROR: AddressSanitizer: heap-buffer-overflow on address
  0x602000000024 at pc 0x55d4c3a1b2f0 bp 0x7ffd5e3c9a40 sp 0x7ffd5e3c9a30
WRITE of size 4 at 0x602000000024 thread T0

    #0 0x55d4c3a1b2f0 in main /home/rafi/report.c:5
    #1 0x7f3a1c829d8f in __libc_start_call_main ...
    #2 0x7f3a1c829e3f in __libc_start_main_impl ...
    #3 0x55d4c3a1b1a4 in _start (/home/rafi/report+0x11a4)
    ← #1 থেকে নিচে C library-র শুরুর কোড; আপনার কোড শুধু #0

0x602000000024 is located 0 bytes after 20-byte region
  [0x602000000010,0x602000000024)
শুরু 0x...10 + 20 (0x14) = 0x...24 → ঠিক শেষ বাইটের পরের বাইট

allocated by thread T0 here:
    #0 0x7f3a1d0b4887 in malloc ../../../../src/libsanitizer/asan/asan_malloc_linux.cpp:69
    #1 0x55d4c3a1b27e in main /home/rafi/report.c:3

SUMMARY: AddressSanitizer: heap-buffer-overflow /home/rafi/report.c:5 in main
Shadow bytes around the buggy address:
=>0x602000000000: fa fa 00 00[04]fa fa fa fa fa fa fa fa fa fa fa
  Addressable: 00   Partially addressable: 01 02 03 04 05 06 07
  Heap left redzone: fa
==8812==ABORTING

UBSan-এর রিপোর্ট — এক লাইনেই সব

UBSan-এর বার্তা অনেক ছোট — ফাইল, লাইন, কলাম আর কারণ:

score.c:9:15: runtime error: signed integer overflow: 2147483647 + 1 cannot be represented in type 'int'
bits.c:4:14: runtime error: shift exponent 32 is too large for 32-bit type 'int'
roster.c:7:13: runtime error: member access within null pointer of type 'const struct student'

একটি পার্থক্য খেয়াল রাখুন: ASan প্রথম ভুলেই প্রোগ্রাম থামায়, কিন্তু UBSan ডিফল্টে বার্তা ছেপে চলতে থাকে। Test-এ প্রথম ভুলেই থামাতে চাইলে -fno-sanitize-recover=all যোগ করুন।

৮ · Valgrind — কোড না বদলেই মেমরি পরীক্ষা

Sanitizer-এর জন্য প্রোগ্রাম আবার compile করতে হয়। কিন্তু যদি source code হাতে না থাকে, বা পুরোনো build সিস্টেম বদলানো কঠিন হয়? তখন Valgrind. Julian Seward-এর তৈরি এই টুলটি ২০০২ সালে প্রথম প্রকাশিত হয়। এটি আপনার প্রোগ্রামকে CPU-তে সরাসরি না চালিয়ে নিজের ভেতরে একটি কৃত্রিম CPU-তে চালায়, আর প্রতিটি instruction-এর ওপর নজর রাখে। এর প্রধান টুল memcheck:

$ gcc -g names.c -o names                                      # -g থাকলে লাইন নম্বর আসবে
$ valgrind --leak-check=full ./names

memcheck দুই জাতের সমস্যা জানায়। প্রথমত Invalid read of size 4 বা Invalid write of size 4 — ASan-এর overflow ও use-after-free-এর মতো। দ্বিতীয়ত leak. নিচের প্রোগ্রামটি তিনটি নাম বানায়, প্রতিটির জন্য make_name ৩২ বাইট malloc করে — কিন্তু শেষে free হয় শুধু শেষটি। Valgrind-এর রিপোর্ট ধরে leak খুঁজে বের করা যাক:

==4321== HEAP SUMMARY:
==4321==     in use at exit: 64 bytes in 2 blocks
==4321==   total heap usage: 4 allocs, 2 frees, 1,120 bytes allocated
৪টি নেওয়া, ২টি ফেরত — ২টি ব্লক হারিয়ে গেছে

==4321== LEAK SUMMARY:
==4321==    definitely lost: 64 bytes in 2 blocks
==4321==    indirectly lost: 0 bytes in 0 blocks
==4321==      possibly lost: 0 bytes in 0 blocks
==4321==    still reachable: 0 bytes in 0 blocks

==4321== 64 bytes in 2 blocks are definitely lost in loss record 1 of 1
==4321==    at 0x4846828: malloc (in /usr/libexec/valgrind/vgpreload_memcheck-amd64-linux.so)
==4321==    by 0x10919E: make_name (names.c:8)
==4321==    by 0x109201: main (names.c:17)

16  for (int i = 0; i < 3; i++) {
17      name = make_name(i);      /* আগের name-এর ঠিকানা মুছে গেল! */
18      printf("%s\n", name);
19      free(name);               /* সমাধান: লুপের ভেতরেই ছাড়ুন */
20  }

ASan না Valgrind?

বাস্তব পরামর্শ: প্রতিদিনের কাজ আর CI-তে ASan + UBSan, কারণ দ্রুত আর stack-এর ভুলও ধরে। source ছাড়া প্রোগ্রাম, অনির্ধারিত মানের সন্দেহ, বা দ্বিতীয় মতামত দরকার হলে Valgrind. দুটো একসাথে একই প্রোগ্রামে চালাবেন না — ASan-সহ build Valgrind-এর নিচে ঠিকমতো চলে না।

৯ · AI-এর যুগে — crash log বুঝতে AI, আর তার ফাঁদ

লম্বা ASan রিপোর্ট বা অচেনা linker error দেখে AI-কে জিজ্ঞেস করা আজ খুব স্বাভাবিক — আর ঠিকভাবে করলে এটা সত্যিই কাজের। AI এমন হাজারো রিপোর্ট দেখেছে, তাই “0 bytes after 20-byte region মানে কী” বা “undefined reference সাধারণত কেন হয়” — এমন প্রশ্নে চমৎকার ব্যাখ্যা দেয়। সমস্যা শুরু হয় যখন আমরা AI-কে ব্যাখ্যাকারী নয়, তদন্তকারী বানিয়ে ফেলি। AI আপনার প্রোগ্রাম চালাতে পারে না, আপনার মেশিনের মেমরি দেখতে পারে না — সে শুধু অনুমান করে।

সবচেয়ে কাজের নিয়ম: পুরো কোডবেস নয়, প্রমাণ দিন। হুবহু error বা trace (ছাঁটাই না করে), সংশ্লিষ্ট ফাংশনগুলো, compile কমান্ড, আর কী আশা করেছিলেন বনাম কী পেলেন। আর চান সমাধান নয়, অনুমান আর যাচাইয়ের উপায়:

AI-এর ডিবাগিং-পরামর্শে সাধারণ ফাঁদ

AI-এর দেওয়া fix গ্রহণের আগে — চেকলিস্ট

• AI যে লাইন ও ফাংশনের কথা বলছে, তা সত্যিই আমার কোড বা রিপোর্টে আছে — মিলিয়ে দেখেছি
• Fix-টি root cause ঠিক করছে, শুধু লক্ষণ (crash, warning) চাপা দিচ্ছে না — “কেন” এক বাক্যে বলতে পারি
• Fix-এর আগে bug পুনরুৎপাদন করেছি, fix-এর পরে একই ইনপুটে আর ঘটছে না
• Fix-এর পরে -Wall -Wextra আর -fsanitize=address,undefined-সহ আবার চালিয়েছি — নতুন রিপোর্ট নেই
• যে ইনপুটে bug ধরা পড়েছিল, সেটি একটি স্থায়ী test হয়ে গেছে
• AI-কে পাঠানো লেখায় password, API key বা গ্রাহকের তথ্য নেই