تسريبات الذاكرة في لغة C: كيف تحدث وكيف تجدها

تسريب الذاكرة ليس ذاكرة اختفت. بل ذاكرة ما تزال ملكك، وما تزال محجوزة، وفقدت القدرة على إعادتها - لأن آخر مؤشّر إليها زال. ولا شيء ينهار. فالبرنامج يواصل العمل، أثقل قليلًا في كل مرة، حتى يفشل شيء ما في النهاية في موضع غير ذي صلة.

تغطّي هذه الصفحة كيف تنشأ التسريبات، والانضباط الذي يمنع معظمها، والأداتين اللتين تجدان الباقي.

كيف يبدو التسريب

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

int main(void) {
    for (int i = 0; i < 3; i++) {
        int *block = malloc(1000 * sizeof *block);
        if (block == NULL) {
            return 1;
        }
        block[0] = i;
        printf("pass %d wrote %d\n", i, block[0]);
        /* بلا free - كل مرور يتخلّى عن 4000 بايت */
    }

    printf("done (3 blocks leaked)\n");
    return 0;
}

يكتب كل تكرار فوق block مؤشّرًا جديدًا. والكتلة السابقة ما تزال مخصَّصة؛ ولا متغيّر يحمل عنوانها؛ ولا يمكن تحريرها أبدًا. فثلاثة تكرارات تفقد اثني عشر كيلوبايتًا. وخادم يفعل ذلك مرة لكل طلب يفقدها إلى الأبد، بالمعدّل الذي تصل به الطلبات.

والإصلاح سطر واحد - free(block); في نهاية الجسم - لكن إدراك أين ينتمي هو المهارة الفعلية.

كيف تحدث التسريبات

1. المؤشّر الضائع

أي إسناد إلى مؤشّر ما زال يحمل المرجع الوحيد لكتلة حيّة يسرّبها.

char *name = malloc(32);
name = malloc(64);     /* the first 32 bytes are now unreachable */

والحلقة أعلاه هي الخطأ نفسه مرتديًا حلقة. وكذلك إعادة إسناد حقل بنية، وكذلك اختصار realloc من calloc وrealloc:

p = realloc(p, n);     /* on failure: p becomes NULL, old block orphaned */

2. العودة المبكرة

على كل مسار خروج من دالة أن يحرّر ما أخذته الدالة سلفًا. والمسار الذي يُنسى هو مسار خطأ دائمًا.

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

/* BUG: مسار الفشل الثاني يسرّب 'a' */
int broken(int n) {
    int *a = malloc((size_t)n * sizeof *a);
    if (a == NULL) {
        return 0;
    }

    int *b = malloc((size_t)n * sizeof *b);
    if (b == NULL) {
        return 0;          /* 'a' ما تزال مخصَّصة والآن لا يمكن بلوغها */
    }

    for (int i = 0; i < n; i++) {
        a[i] = i;
        b[i] = i * i;
    }
    int total = a[n - 1] + b[n - 1];

    free(a);
    free(b);
    return total;
}

int main(void) {
    printf("%d\n", broken(5));
    return 0;
}

المسار السعيد صحيح ومسار الخطأ يسرّب، ولهذا يصمد هذا أمام الاختبار: فالفرع الفاشل لا يُنفَّذ تقريبًا أثناء التطوير. والإصلاح قسم تنظيف واحد يقفز إليه كل مسار:

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

int fixed(int n) {
    int *a = NULL;
    int *b = NULL;
    int total = 0;

    a = malloc((size_t)n * sizeof *a);
    if (a == NULL) {
        goto cleanup;
    }

    b = malloc((size_t)n * sizeof *b);
    if (b == NULL) {
        goto cleanup;
    }

    for (int i = 0; i < n; i++) {
        a[i] = i;
        b[i] = i * i;
    }
    total = a[n - 1] + b[n - 1];

cleanup:
    free(a);       /* free(NULL) معرَّفة بألّا تفعل شيئًا */
    free(b);
    return total;
}

int main(void) {
    printf("%d\n", fixed(5));
    return 0;
}

وهذا هو الاستخدام الوحيد لـ goto الذي يوصي به مبرمجو C المخضرمون فعليًا. وهو يعمل لأن كل مؤشّر يبدأ بـ NULL وfree(NULL) لا تفعل شيئًا، فتكون كتلة خروج واحدة صحيحة مهما بلغت الدالة.

3. الملكية غير الواضحة

أدقّ التسريبات ليست أخطاء برمجية أصلًا - بل دالّتان تختلفان في تحديد مَن كانت مهمّته.

char *build_message(void);   /* does the caller free this? */
void  store(char *text);     /* does store take ownership? */

إن أرجعت build_message ذاكرةً مخصَّصة ونسختها store، فعلى المستدعي التحرير. وإن احتفظت store بالمؤشّر، فعلى المستدعي ألّا يحرّر. ولا شيء في الشيفرة يقول أيّهما، فيُتَّخذ أحد الافتراضين مرتين - فتحصل إما على تسريب وإما على تحرير مزدوج.

والعلاج عرف يُذكَر في تعليق بجوار كل دالة تخصّص:

/* Returns a newly allocated string; the caller must free it. */
char *build_message(void);

/* Takes ownership of 'text'; it will be freed by store_free(). */
void store(char *text);

اكتب القاعدة عند الدالة لا في وثيقة تصميم. فهي أعلى عادة قيمةً في إدارة الذاكرة بلغة C.

انضباط الملكية

أربع قواعد تغطّي كل شيء تقريبًا:

1. لكل تخصيص مالك واحد بالضبط - قطعة شيفرة واحدة مسؤولة عن تحريره.
2. اقرن كل دالة تخصّص بأخرى تحرّر. vec_init / vec_free، وconfig_load / config_free. فالتماثل يجعل الاستدعاء المفقود مرئيًا.
3. حرّر في الطبقة نفسها التي خصّصت، ما لم ينقل تعليق الدالة الملكية صراحةً.
4. اضبط المؤشّر على NULL بعد تحريره، ليتعطّل استخدام لاحق عرضي عند موضع الخطأ بدل إفساد الكومة بهدوء.

إيجاد التسريبات: valgrind

على لينكس، لا يحتاج valgrind إلى إعادة ترجمة، وإن كانت رموز التنقيح تجعل التقرير مقروءًا:

gcc -g -O0 program.c -o program
valgrind --leak-check=full --show-leak-kinds=all ./program

وللحلقة المسرِّبة في أعلى هذه الصفحة، ينتهي التقرير بشيء مثل:

==12345== HEAP SUMMARY:
==12345==     in use at exit: 12,000 bytes in 3 blocks
==12345==   total heap usage: 3 allocs, 0 frees, 12,000 bytes allocated
==12345==
==12345== 12,000 bytes in 3 blocks are definitely lost in loss record 1 of 1
==12345==    at 0x4C2FB0F: malloc (vg_replace_malloc.c:299)
==12345==    by 0x108671: main (program.c:6)
==12345==
==12345== LEAK SUMMARY:
==12345==    definitely lost: 12,000 bytes in 3 blocks

اقرأه من الأسفل. فـ "definitely lost" تعني أنه لم يكن هناك مؤشّر إلى الكتلة عند الخروج - وهذا تسريب حقيقي. ويسمّي أثر المكدّس سطر الـ malloc التي أنشأتها، لا السطر الذي ضاعت فيه، وهذا يكفي عادةً لإيجاد free المفقودة.

وتظهر فئتان أخريان:

• indirectly lost - كتل لا يمكن بلوغها إلا عبر كتلة ضاعت هي نفسها، مثل عناصر قائمة مترابطة مسرَّبة. أصلح ما هو "definitely lost" فتختفي هذه.
• still reachable - مخصَّصة عند الخروج لكن مع مؤشّر حيّ، وهي عادةً مخزن مؤقّت عام. وليست تسريبًا بالمعنى الخطير، لكنها تستحق التحرير ليبقى التقرير فارغًا.

كما يلتقط valgrind قراءات الذاكرة غير المهيّأة والكتابات بعد نهاية كتلة، وهو غالبًا كيف تكتشف الخطأ الكامن وراء التسريب.

إيجاد التسريبات: AddressSanitizer

AddressSanitizer مدمج في GCC وClang، ويعمل أسرع بكثير من valgrind، ويعمل حيث لا يعمل valgrind (بما في ذلك macOS الحالي):

gcc -g -fsanitize=address -fno-omit-frame-pointer program.c -o program
./program

ويُطبَع تقرير التسريب عند الخروج تلقائيًا:

=================================================================
==12345==ERROR: LeakSanitizer: detected memory leaks

Direct leak of 12000 byte(s) in 3 object(s) allocated from:
    #0 0x7f... in malloc
    #1 0x1086... in main program.c:6

SUMMARY: AddressSanitizer: 12000 byte(s) leaked in 3 allocation(s).

كما يحوّل ASan الاستخدام بعد التحرير وفيضانات مخازن الكومة إلى إنهاءات فورية واضحة التسمية بدل إفساد غامض لاحقًا. ابنِ تشغيلات الاختبار به مفعّلًا؛ وابنِ الإصدارات به معطّلًا، فهو يكلّف ذاكرة وسرعة.

وإن لم يعمل كشف التسريبات على منصّتك، فاضبط ASAN_OPTIONS=detect_leaks=1 في البيئة قبل التشغيل.

إصلاح برنامج مسرِّب خطوة بخطوة

إليك برنامجًا صغيرًا بثلاثة تسريبات منفصلة:

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

char *shout(const char *text) {
    size_t len = strlen(text);
    char *out = malloc(len + 1);
    if (out == NULL) {
        return NULL;
    }
    for (size_t i = 0; i < len; i++) {
        out[i] = (char)(text[i] - 32 * (text[i] >= 'a' && text[i] <= 'z'));
    }
    out[len] = '\0';
    return out;
}

int main(void) {
    /* التسريب 1: لا تُحرَّر نتيجة shout أبدًا */
    printf("%s\n", shout("hello"));

    /* التسريب 2: يُكتب فوق buf، فتضيع الكتلة الأولى */
    char *buf = malloc(16);
    buf = malloc(32);
    strcpy(buf, "second block");
    printf("%s\n", buf);
    free(buf);

    /* التسريب 3: العودة المبكرة تتخطّى التحرير */
    int *nums = malloc(4 * sizeof *nums);
    if (nums == NULL) {
        return 1;
    }
    nums[0] = 1;
    if (nums[0] != 0) {
        printf("bailing out\n");
        return 0;
    }
    free(nums);
    return 0;
}

يبلّغ valgrind عن ثلاثة سجلّات "definitely lost" بثلاثة أرقام أسطر مختلفة. ومُصلَحة واحدًا تلو الآخر:

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

/* تُرجِع سلسلة نصية مخصَّصة حديثًا؛ وعلى المستدعي تحريرها. */
char *shout(const char *text) {
    size_t len = strlen(text);
    char *out = malloc(len + 1);
    if (out == NULL) {
        return NULL;
    }
    for (size_t i = 0; i < len; i++) {
        out[i] = (char)(text[i] - 32 * (text[i] >= 'a' && text[i] <= 'z'));
    }
    out[len] = '\0';
    return out;
}

int main(void) {
    /* الإصلاح 1: احمل المؤشّر، واستخدمه، وحرّره */
    char *loud = shout("hello");
    if (loud == NULL) {
        return 1;
    }
    printf("%s\n", loud);
    free(loud);

    /* الإصلاح 2: تخصيص واحد، بحجم صحيح من أول مرة */
    char *buf = malloc(32);
    if (buf == NULL) {
        return 1;
    }
    strcpy(buf, "second block");
    printf("%s\n", buf);
    free(buf);
    buf = NULL;

    /* الإصلاح 3: كل مسار خروج يحرّر */
    int *nums = malloc(4 * sizeof *nums);
    if (nums == NULL) {
        return 1;
    }
    nums[0] = 1;
    if (nums[0] != 0) {
        printf("bailing out\n");
        free(nums);
        return 0;
    }
    free(nums);
    return 0;
}

الإصلاح 1 هو تعليق الملكية مجسَّدًا: فـ shout تخصّص وmain تحرّر. والإصلاح 2 يزيل التخصيص المزدوج كليًا بدل تحرير الأول - فالشيفرة الأبسط هي أيضًا الشيفرة الصحيحة. والإصلاح 3 يضيف free المفقودة عند العودة المبكرة؛ ومع تخصيصات أكثر، يتوسّع عنوان cleanup: الواحد المعروض سابقًا أفضل من تكرار التحريرات.

عادات تمنع التسريبات

• اكتب free فورًا بعد كتابة malloc، ثم املأ الشيفرة بينهما.
• امنح كل دالة تخصّص دالةَ تحرير مقابلة.
• اذكر الملكية في تعليق على أي دالة تُرجِع أو تأخذ مؤشّرًا خصّصته.
• استخدم كتلة خروج cleanup: واحدة في الدوال التي تحمل عدة تخصيصات.
• شغّل اختباراتك تحت -fsanitize=address كأمر معتاد، لا حين يبدو شيء خاطئًا فقط.
• عامِل "definitely lost: 0 bytes" كجزء من تشغيل اختبار ناجح.