Как объявление переменной с помощью malloc приводит к потере битов? - PullRequest
0 голосов
/ 17 февраля 2019

Сначала я запустил valgrind, чтобы убедиться, что (при настройках по умолчанию) ошибок нет.Затем я решил проверить на утечки что-то вроде: --leak-check=full

У меня есть код, похожий на char* variable=malloc(sizeof(char)*(strlen(in)+1));, и valgrind сообщает, что память «определенно потеряна».

Единственная другая строка кода, к которой у меня есть доступ (это в функции обратного вызова библиотеки), - это строка кода, где объявлено in.Это аргумент функции типа void * (хотя в этом случае я надеюсь, что мы можем смело предположить, что значение завершено нулем.)

1 Ответ

0 голосов
/ 17 февраля 2019

Имея

#include <stdlib.h>

char * G;

int main()
{
   char * l = malloc(10);

   G = malloc(20);
}

Выполнение в valgrind дает:

pi@raspberrypi:/tmp $ valgrind --leak-check=full ./a.out
==11087== Memcheck, a memory error detector
==11087== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al.
==11087== Using Valgrind-3.13.0 and LibVEX; rerun with -h for copyright info
==11087== Command: ./a.out
==11087== 
==11087== 
==11087== HEAP SUMMARY:
==11087==     in use at exit: 30 bytes in 2 blocks
==11087==   total heap usage: 2 allocs, 0 frees, 30 bytes allocated
==11087== 
==11087== 10 bytes in 1 blocks are definitely lost in loss record 1 of 2
==11087==    at 0x4847568: malloc (vg_replace_malloc.c:299)
==11087==    by 0x10453: main (mm.c:7)
==11087== 
==11087== LEAK SUMMARY:
==11087==    definitely lost: 10 bytes in 1 blocks
==11087==    indirectly lost: 0 bytes in 0 blocks
==11087==      possibly lost: 0 bytes in 0 blocks
==11087==    still reachable: 20 bytes in 1 blocks
==11087==         suppressed: 0 bytes in 0 blocks
==11087== Reachable blocks (those to which a pointer was found) are not shown.
==11087== To see them, rerun with: --leak-check=full --show-leak-kinds=all
==11087== 
==11087== For counts of detected and suppressed errors, rerun with: -v
==11087== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 6 from 3)

malloc(10) определенно потеряно, потому что нет доступа к нему приконец выполнения (здесь из main )

malloc(20) не потерян, потому что все еще доступен через G

...