ডায়নামিক মেমরি — চলার সময় দরকারমতো জায়গা নেওয়া আর ফেরত দেওয়া

১ · সমস্যা: কতজন আসবে, আগে জানা নেই

ধরুন আপনি একটি কোচিং সেন্টারের জন্য রেজাল্ট-প্রোগ্রাম লিখছেন। পর্ব ১৬-এ শিখেছেন, অনেকগুলো নম্বর রাখতে array লাগে — int marks[100];. কিন্তু প্রশ্ন হলো, ১০০ কেন? এই ব্যাচে ৩৫ জন, পরের ব্যাচে হয়তো ২৪০ জন। আর যদি প্রোগ্রামটি সারা দেশের বোর্ড পরীক্ষার ফল সামলায়, তাহলে সংখ্যাটি কয়েক লাখ।

আকার আগে থেকে ঠিক করে দিলে দুটি বিপদের একটি ঘটবেই:

বাস্তবের প্রায় সব প্রোগ্রামেই এই সমস্যা। একটি চ্যাট অ্যাপ জানে না আজ কতগুলো মেসেজ আসবে। একটি ই-কমার্স সার্ভার জানে না ঈদের আগের রাতে কতগুলো অর্ডার আসবে। একটি ছবি-এডিটর জানে না আপনি কত বড় ছবি খুলবেন। সংখ্যাটি জানা যায় প্রোগ্রাম চলার সময়, কোড লেখার সময় নয়।

২ · একটি প্রোগ্রামের মেমরির মানচিত্র

Heap কোথায় থাকে বুঝতে হলে আগে পুরো ছবিটি দেখা দরকার। আপনি যখন একটি প্রোগ্রাম চালান, অপারেটিং সিস্টেম তাকে নিজস্ব একটি মেমরি-এলাকা দেয়। সেই এলাকা কয়েকটি ভাগে সাজানো — একে বলে প্রোগ্রামের memory map. প্রতিটি ভাগের কাজ আলাদা, নিয়ম আলাদা। নিচের ডায়াগ্রামে “পরে” চেপে একটি একটি করে ভাগ দেখুন:

int main(void) { ... }      /* সব ফাংশনের machine code */
"Hello, Dhaka!"              /* string literal — প্রায়ই পাশের read-only অংশে */

int total_students = 35;     /* মান দেওয়া global → data */
int counter;                 /* মান না দেওয়া global → bss (শুরুতে 0) */
static int calls = 0;        /* static → bss (0 দেওয়া) */

int *marks = malloc(n * sizeof *marks);
/* marks নিজে stack-এ থাকে, কিন্তু যে block-এর ঠিকানা সে ধরে আছে, সেটি heap-এ */
free(marks);                 /* ফেরত না দিলে প্রোগ্রাম শেষ হওয়া পর্যন্ত আটকে থাকে */

void report(void) {
    int i;                   /* লোকাল → stack */
    char name[20];            /* লোকাল array → stack */
}                            /* ফাংশন শেষ → পুরো frame মুছে গেল */

Stack  : ফাংশনের ভেতরে ফাংশন ডাকলে  → নিচে নামে
Heap   : malloc ডাকলে                → উপরে ওঠে
Stack-এর সীমা ছোট (প্রায়ই 1-8 MB) — পেরোলে stack overflow
Heap অনেক বড় — যতক্ষণ RAM আর OS দেয়

int batch_size = 35;               /* → Data  */
int main(void) {                   /* → Text  */
    int n = batch_size;            /* → Stack */
    int *marks = malloc(n * sizeof *marks);
                                   /* marks → Stack, block → Heap */
    free(marks);
    return 0;
}

৩ · Stack বনাম heap — কোনটি কখন

দুটোই মেমরি, দুটোই RAM-এ থাকে। তাহলে পার্থক্য কোথায়? পার্থক্য হলো কে জায়গার হিসাব রাখে আর জায়গাটি কতক্ষণ থাকে।

তাহলে নিয়মটি সহজ। ছোট, নির্দিষ্ট আকারের, শুধু এই ফাংশনেই লাগবে — stack. আকার চলার সময় জানা যাবে, অনেক বড়, অথবা ফাংশন শেষ হওয়ার পরেও লাগবে — heap. শেষ শর্তটি খুব গুরুত্বপূর্ণ। কোনো ফাংশন যদি একটি নতুন array বানিয়ে ফেরত দিতে চায়, লোকাল array-র ঠিকানা ফেরত দিলে চলবে না — ফাংশন শেষ হতেই সেই জায়গা মুছে যায়। তখন heap-ই একমাত্র ভরসা।

৪ · চারটি ফাংশন — malloc, calloc, realloc, free

Heap ব্যবহারের সব কাজ চারটি ফাংশনে। চারটিই আছে <stdlib.h> header-এ। এদের পেছনে কাজ করে allocator নামের একটি কোড, যে heap-এর কোন অংশ খালি আর কোনটি কার — সেই হিসাব রাখে।

তিনটি অভ্যাস যা প্রতিবার লাগবে

১. সবসময় NULL যাচাই। মেমরি না পেলে malloc একটি NULL pointer ফেরত দেয়। যাচাই না করে সেটিতে লিখলে প্রোগ্রাম crash করে। “আমার ল্যাপটপে 16 GB RAM, ব্যর্থ হবে কেন?” — কারণ ছোট ফোন, এমবেডেড বোর্ড, বা মেমরি-সীমা দেওয়া সার্ভারেও এই কোড চলতে পারে। আর ভুল ইনপুটে n যদি বিশাল হয়, তখনো ব্যর্থ হবে।

২. sizeof *p ব্যবহার করুন, টাইপের নাম নয়। malloc(n * sizeof(int)) চলে, কিন্তু পরে কেউ p-কে double * বানালে এই লাইন বদলাতে ভুলে যাবে। malloc(n * sizeof *p) লিখলে p যে টাইপেরই হোক, আকার ঠিক থাকে। আর C-তে malloc-এর ফলাফলকে cast করার দরকার নেই (C++-এ লাগে, C-তে নয়)।

৩. গুণফলের overflow খেয়াল করুন। n * sizeof *p যদি size_t-এর সীমা ছাড়িয়ে যায়, পর্ব ০৮-এর wraparound-এর মতো ঘুরে ছোট একটি সংখ্যা হয়ে যায়। তখন malloc খুশি মনে ছোট block দেবে, আর আপনি বড় ভেবে লিখতে থাকবেন — buffer overflow. বাইরের ইনপুট থেকে আসা n-এর ক্ষেত্রে আগে সীমা যাচাই করুন, অথবা calloc(n, sizeof *p) ব্যবহার করুন — আধুনিক calloc এই গুণফল নিজেই যাচাই করে।

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

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

int main(void) {
    int n;
    if (scanf("%d", &n) != 1 || n <= 0) return 1;
    int *marks = malloc((size_t)n * sizeof *marks);
    if (marks == NULL) { printf("Out of memory\n"); return 1; }
    double sum = 0;
    for (int i = 0; i < n; i++) {
        if (scanf("%d", &marks[i]) != 1) marks[i] = 0;
        sum += marks[i];
    }
    double avg = sum / n;
    printf("Average: %.2f\nAbove average:", avg);
    for (int i = 0; i < n; i++)
        if (marks[i] > avg) printf(" %d", marks[i]);
    printf("\n");
    free(marks);
    marks = NULL;
    return 0;
}

৫ · একটি block-এর জীবনচক্র — জন্ম থেকে “মৃত্যুর পরে”

এবার heap-এর ভেতরে চোখ রাখি। নিচের কোডে একটি block নেওয়া হচ্ছে, ব্যবহার হচ্ছে, ফেরত দেওয়া হচ্ছে — তারপর একটি সাধারণ ভুল। ডান দিকে heap-এর একটি block-এর অবস্থা খেয়াল করুন। শেষের দিকের ধাপগুলোতে লেখা আছে “যা ঘটতে পারে” — কারণ সেখানে C-র নিয়ম আর কোনো নিশ্চয়তা দেয় না।

1int *p = malloc(3 * sizeof *p);2if (p == NULL) return 1;3p[0] = 50; p[1] = 70; p[2] = 90;4free(p);5char *msg = malloc(12);6strcpy(msg, "OTP 482913");7p[0] = 99;   /* use-after-free! */8printf("msg = %s\n", msg);

৬ · পাঁচটি বিপজ্জনক ভুল — এবং কেন এগুলো বাস্তবে এত ক্ষতি করে

Heap-এর প্রায় সব বাগ এই পাঁচ ধরনের কোনো একটি। নামগুলো মনে রাখুন — কারণ sanitizer আর Valgrind ঠিক এই নামেই ভুল জানায়।

Memory leak — হোটেলের চাবি যে কখনো ফেরত আসে না

একটি হোটেলে ১০০টি রুম। প্রতিদিন কয়েকজন অতিথি চেক-আউটের সময় চাবি ফেরত না দিয়ে চলে যান। রিসেপশনের খাতায় রুমগুলো তখনো “ভাড়া দেওয়া” লেখা থাকে, অথচ ভেতরে কেউ নেই। প্রথম সপ্তাহে কেউ টের পায় না। কয়েক মাস পরে দেখা যায় হোটেল প্রায় খালি, কিন্তু নতুন অতিথিকে দেওয়ার মতো একটি রুমও নেই।

Memory leak ঠিক এমন। একটি ছোট প্রোগ্রাম যা কয়েক সেকেন্ড চলে বন্ধ হয়, তার leak প্রায় চোখেই পড়ে না — প্রোগ্রাম শেষ হলে অপারেটিং সিস্টেম পুরো মেমরি ফেরত নিয়ে নেয়। আসল বিপদ দীর্ঘ সময় চলা প্রোগ্রামে: ওয়েব সার্ভার, ডেটাবেস, মোবাইল অ্যাপ, রাউটারের firmware — যেগুলো দিনের পর দিন বন্ধ হয় না। নিচের সার্ভারটি প্রতিটি request-এ মাত্র 1 KB হারায়:

1while (server_is_running) {2    char *buf = malloc(1024);3    read_request(buf);4    send_reply(buf);56}

Use-after-free কেন হ্যাকারদের প্রিয়

Leak প্রোগ্রামকে ধীরে ধীরে মারে, কিন্তু গোপন তথ্য ফাঁস করে না। Use-after-free আরও বিপজ্জনক, কারণ free হওয়া block প্রায়ই অন্য কারও কাছে যায়। আক্রমণকারী সেই নতুন ডেটা নিজে বেছে দিতে পারলে পুরোনো pointer দিয়ে চলা কোড তারই সাজানো ডেটা পড়বে। ব্রাউজারে এটি সবচেয়ে সহজ, কারণ যেকোনো ওয়েবসাইটের JavaScript ব্রাউজারকে দিয়ে মেমরি নেওয়া-ছাড়া করাতে পারে। এজন্যই বড় ব্রাউজারগুলোর গুরুতর নিরাপত্তা-ত্রুটির তালিকায় use-after-free বছরের পর বছর উপরের দিকে থাকে (বিস্তারিত ভাবনার প্রশ্ন ৩-এ)।

Double free আর ভুল জিনিস free

Allocator প্রতিটি block-এর আশেপাশে নিজের হিসাব রাখে — block কত বড়, পরের খালি block কোনটি। একই block দুবার free করলে খালি-তালিকায় একই জায়গা দুবার ঢোকে। ফলে পরে দুটি আলাদা malloc একই জায়গা পেতে পারে — যা আবার use-after-free-র দরজা খোলে। Stack-এর array বা block-এর মাঝখানের ঠিকানা free করলে allocator এমন জায়গায় নিজের হিসাব খোঁজে যেখানে তা নেই। আধুনিক glibc অনেক ক্ষেত্রেই এটি ধরে ফেলে প্রোগ্রাম থামিয়ে দেয়:

free(): double free detected in tcache 2
Aborted (core dumped)

ভুলটি অন্তত সশব্দে ধরা পড়ল — কিন্তু সব ভুল এভাবে ধরা পড়ে না।

৭ · বাড়তে পারে এমন array — capacity দ্বিগুণ করার কৌশল

অনেক সময় শুরুতে সংখ্যাটিও জানা থাকে না। যেমন একটি ফাইল থেকে লাইন পড়ছেন, কতগুলো লাইন জানেন না। Python-এ আপনি list.append() লেখেন, C++-এ vector.push_back(). এই সুবিধাজনক জিনিসগুলোর ভেতরে আসলে কী আছে? একটি heap array, আর realloc. একে বলে dynamic array.

কৌশলটি হলো দুটি সংখ্যা আলাদা রাখা: size — কতগুলো ঘর এখন ভরা, আর capacity — মোট কতগুলো ঘরের জায়গা নেওয়া আছে। যতক্ষণ size < capacity, নতুন জিনিস সরাসরি পরের ঘরে বসে। ঘর ফুরালে capacity দ্বিগুণ করা হয়। নিচে দেখুন ১০, ২০, ৩০ … ৮০ যোগ করলে কী ঘটে:

1if (size == cap) {2    size_t newcap = cap ? cap * 2 : 1;3    int *tmp = realloc(data, newcap * sizeof *tmp);4    if (tmp == NULL) { /* data এখনো অক্ষত */ }5    data = tmp;  cap = newcap;6}7data[size++] = x;

এবার পুরো কৌশলটি চালিয়ে দেখুন। প্রোগ্রামটি ১ থেকে ১০ পর্যন্ত সংখ্যার বর্গ রাখছে, আর প্রতিবার জায়গা বাড়ানোর সময় একটি লাইন ছাপছে:

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

int main(void) {
    int *data = NULL;
    size_t size = 0, cap = 0;
    for (int x = 1; x <= 10; x++) {
        if (size == cap) {
            size_t newcap = cap ? cap * 2 : 1;
            int *tmp = realloc(data, newcap * sizeof *tmp);
            if (tmp == NULL) { free(data); return 1; }
            printf("full at size %zu: capacity %zu -> %zu\n", size, cap, newcap);
            data = tmp;
            cap = newcap;
        }
        data[size++] = x * x;
    }
    printf("size=%zu capacity=%zu last=%d\n", size, cap, data[size - 1]);
    free(data);
    return 0;
}

৮ · ভুল ধরার যন্ত্র — AddressSanitizer, Valgrind আর মালিকানার নিয়ম

আগেই দেখেছেন, heap-এর বাগ প্রায়ই নীরব থাকে। চোখে দেখে খোঁজা প্রায় অসম্ভব। তাই পেশাদাররা টুল ব্যবহার করেন। পর্ব ০৩-এ sanitizer-এর কথা বলেছিলাম — মেট্রো স্টেশনের সিকিউরিটি গেটের মতো। এবার তার আসল কাজ দেখার সময়।

gcc -g -fsanitize=address grow.c -o grow && ./grow
valgrind --leak-check=full ./grow

ধরুন উপরের অংশ ৫-এর মতো use-after-free আছে। ASan সঙ্গে সঙ্গে প্রোগ্রাম থামিয়ে এমন রিপোর্ট দেবে (সংক্ষেপে):

ERROR: AddressSanitizer: heap-use-after-free on address 0x602000000010
WRITE of size 4 at 0x602000000010 thread T0
    #0 in main uaf.c:7
freed by thread T0 here:
    #1 in main uaf.c:4
previously allocated by thread T0 here:
    #1 in main uaf.c:1

রিপোর্টটি পড়তে শিখুন — এতে তিনটি তথ্য আছে: কোথায় ভুল ব্যবহার হলো (লাইন ৭), কোথায় free হয়েছিল (লাইন ৪), আর কোথায় নেওয়া হয়েছিল (লাইন ১)। পুরো জীবনচক্র এক নজরে! Linux-এ ASan প্রোগ্রাম শেষে leak-ও জানায় — LeakSanitizer: detected memory leaks. আর Valgrind leak পেলে বলে definitely lost: 1024 bytes in 1 blocks; কোনো leak না থাকলে বলে All heap blocks were freed -- no leaks are possible. শেষ লাইনটিই আপনার লক্ষ্য।

মালিকানার নিয়ম — কে free করবে?

টুল ভুল ধরে, কিন্তু ভুল না করার উপায় হলো নকশা। বড় প্রোগ্রামে একটি block এক ফাংশনে তৈরি হয়, আরেক ফাংশনে ব্যবহার হয়, তৃতীয় কোনো ফাংশনে হয়তো রাখা হয়। তখন প্রশ্ন ওঠে — free কে করবে? দুজনেই করলে double free, কেউ না করলে leak. সমাধান হলো ownership বা মালিকানার স্পষ্ট নিয়ম:

• যে ফাংশন malloc করে ফেরত দেয়, সে লিখে জানাবে: “ফেরত পাওয়া block-টি ডাকা ফাংশনকে free করতে হবে।” যেমন standard library-র strdup বা getline-এর নথিতে ঠিক এমন কথা লেখা থাকে।
• যে নেয়, সে ছাড়ে — একই স্তরে। যতটা সম্ভব একই ফাংশনে বা জোড়া ফাংশনে (list_create / list_destroy) নেওয়া আর ছাড়া রাখুন।
• ধার দেওয়া মানে মালিকানা দেওয়া নয়। কোনো ফাংশন শুধু পড়ার জন্য pointer পেলে সে কখনো free করবে না।
• সব বের হওয়ার পথে free. ফাংশনের মাঝখানে error-এ return করলেও আগে নেওয়া block ছাড়তে হবে — leak-এর সবচেয়ে সাধারণ উৎস এটাই।

৯ · AI-এর যুগে ডায়নামিক মেমরি

AI-কে “একটি dynamic array লিখে দাও” বললে কয়েক সেকেন্ডে কোড পাবেন, এবং বেশিরভাগ সময় তা চলবেও। সমস্যা হলো, মেমরির বাগ “চলে” — আপনার ছোট পরীক্ষায় কোনো লক্ষণ দেখায় না। AI নিজে কোডটি দীর্ঘ সময় চালায় না, sanitizer দিয়েও না। তাই এই দায়িত্ব আপনার।

AI সাধারণত যেসব মেমরি-ভুল করে

AI-এর মেমরি-কোড হাতে পেলে — যাচাইয়ের চেকলিস্ট

• প্রতিটি malloc/calloc/realloc-এর ঠিক পরে NULL যাচাই আছে
• প্রতিটি নেওয়া block-এর জন্য ঠিক একটি free খুঁজে পেয়েছি — error-এ বের হওয়ার পথেও
• কোথাও p = realloc(p, …) নেই, আর আকারে sizeof *p আছে
• free-এর পরে সেই pointer আর ব্যবহার হয়নি (দরকার হলে NULL করা হয়েছে)
• -fsanitize=address দিয়ে চালিয়েছি, অস্বাভাবিক ইনপুটসহ — একটিও রিপোর্ট নেই