Использование неинициализированной памяти c как исправить

There are two main techniques people use to delay creation of an object. I will show how they apply for a single object, but you can extend these techniques to a static or dynamic array.

Aligned Storage

The first approach is using std::aligned_storage, which is a glorified char array with alignment taken into consideration:

template<typename T>
class Uninitialized1 {
    std::aligned_storage_t<sizeof(T)> _data;

public:
    template<typename... Args>
    void construct(Args... args) {
        new (&_data) T(args...);
        std::cout << "Data: " << *reinterpret_cast<T*>(&_data) << "n";
    }
};

Note that I have left out things like perfect forwarding to keep the main point.

One drawback of this is that there’s no way to have a constexpr constructor that takes a value to copy into the class. This makes it unsuitable for implementing std::optional.

Unions

A different approach uses plain old unions. With aligned storage, you have to be careful, but with unions, you have to be doubly careful. Don’t assume my code is bug-free as is.

template<typename T>
class Uninitialized2 {
    union U {
        char dummy;
        T data;

        U() {}
        U(T t) : data(t) {
            std::cout << "Constructor data: " << data << "n";
        }
    } u;

public:
    Uninitialized2() = default;
    Uninitialized2(T t) : u(t) {}

    template<typename... Args>
    void construct(Args... args) {
        new (&u.data) T(args...);
        std::cout << "Data: " << u.data << "n";
    }
};

A union stores a strongly-typed object, but we put a dummy with trivial construction before it. This means that the default constructor of the union (and of the whole class) can be made trivial. However, we also have the option of initializing the second union member directly, even in a constexpr-compatible way.

One very important thing I left out is that you need to manually destroy these objects. You will need to manually invoke destructors, and that should bother you, but it’s necessary because the compiler can’t guarantee the object is constructed in the first place. Please do yourself a favour and study up on these techniques in order to learn how to utilize them properly, as there are some pretty subtle details, and things like ensuring every object is properly destroyed can become tricky.

I (barely) tested these code snippets with a small class and driver:

struct C {
    int _i;

public:
    explicit C(int i) : _i(i) {
        std::cout << "Constructing C with " << i << "n";
    }

    operator int() const { return _i; }
};

int main() {
    Uninitialized1<C> u1;
    std::cout << "Made u1n";
    u1.construct(5);

    std::cout << "n";

    Uninitialized2<C> u2;
    std::cout << "Made u2n";
    u2.construct(6);

    std::cout << "n";

    Uninitialized2<C> u3(C(7));
    std::cout << "Made u3n";
}

The output with Clang was as follows:

Made u1
Constructing C with 5
Data: 5

Made u2
Constructing C with 6
Data: 6

Constructing C with 7
Constructor data: 7
Made u3

There are two main techniques people use to delay creation of an object. I will show how they apply for a single object, but you can extend these techniques to a static or dynamic array.

Aligned Storage

The first approach is using std::aligned_storage, which is a glorified char array with alignment taken into consideration:

template<typename T>
class Uninitialized1 {
    std::aligned_storage_t<sizeof(T)> _data;

public:
    template<typename... Args>
    void construct(Args... args) {
        new (&_data) T(args...);
        std::cout << "Data: " << *reinterpret_cast<T*>(&_data) << "n";
    }
};

Note that I have left out things like perfect forwarding to keep the main point.

One drawback of this is that there’s no way to have a constexpr constructor that takes a value to copy into the class. This makes it unsuitable for implementing std::optional.

Unions

A different approach uses plain old unions. With aligned storage, you have to be careful, but with unions, you have to be doubly careful. Don’t assume my code is bug-free as is.

template<typename T>
class Uninitialized2 {
    union U {
        char dummy;
        T data;

        U() {}
        U(T t) : data(t) {
            std::cout << "Constructor data: " << data << "n";
        }
    } u;

public:
    Uninitialized2() = default;
    Uninitialized2(T t) : u(t) {}

    template<typename... Args>
    void construct(Args... args) {
        new (&u.data) T(args...);
        std::cout << "Data: " << u.data << "n";
    }
};

A union stores a strongly-typed object, but we put a dummy with trivial construction before it. This means that the default constructor of the union (and of the whole class) can be made trivial. However, we also have the option of initializing the second union member directly, even in a constexpr-compatible way.

One very important thing I left out is that you need to manually destroy these objects. You will need to manually invoke destructors, and that should bother you, but it’s necessary because the compiler can’t guarantee the object is constructed in the first place. Please do yourself a favour and study up on these techniques in order to learn how to utilize them properly, as there are some pretty subtle details, and things like ensuring every object is properly destroyed can become tricky.

I (barely) tested these code snippets with a small class and driver:

struct C {
    int _i;

public:
    explicit C(int i) : _i(i) {
        std::cout << "Constructing C with " << i << "n";
    }

    operator int() const { return _i; }
};

int main() {
    Uninitialized1<C> u1;
    std::cout << "Made u1n";
    u1.construct(5);

    std::cout << "n";

    Uninitialized2<C> u2;
    std::cout << "Made u2n";
    u2.construct(6);

    std::cout << "n";

    Uninitialized2<C> u3(C(7));
    std::cout << "Made u3n";
}

The output with Clang was as follows:

Made u1
Constructing C with 5
Data: 5

Made u2
Constructing C with 6
Data: 6

Constructing C with 7
Constructor data: 7
Made u3

Нравится ресурс? Помоги проекту!

c6001: использование неинициализированной памяти. Почему?

• Подписаться на тему
• Сообщить другу
• Скачать/распечатать тему

Сообщ. #1 , 21.01.23, 11:30
	Есть код: int *x; … x = new int[1000]; … if( … ) { … }else {   int xMinMax[2];   xMinMax[0] = xMinMax[1] = x[0]; // здесь подчёркивает и пишет ‘c6001: Использование неинициализированной памяти «*x»‘   … } Пишет такое предупреждение (см. код). VisualStudio 2019. Отчего так?

grgdvo	Сообщ. #2 , 21.01.23, 14:36
Member Рейтинг (т): 21	Вокруг x = new int[1000]; никаких условий нет?? Все линейно??

Dushevny	Сообщ. #3 , 21.01.23, 14:40
Member Рейтинг (т): 16	Потому что после new() для каждого элемента вызывается конструктор по-умолчанию. Для int он ничего не делает, в том числе и не обнуляет переменную. Поэтому каждый элемент этого массива остается непроинициализированным, т.е. содержит мусор, который был в куче на месте этого массива перед его созданием. Сообщение отредактировано: Dushevny — 21.01.23, 14:42

Majestio	Сообщ. #4 , 21.01.23, 15:01
Злое Солнце Рейтинг (т): 10	Цитата Dushevny @ 21.01.23, 14:40 для каждого элемента вызывается конструктор по-умолчанию Хе-хе … вопрос интересный! Что-то мне казалось, что для POD-типов нет ни конструкторов (не путать с аллокаторами), не их вызовов, ни по-умоланию и ваапще никак! И тут такой ответ, что я в тупике … Вызываю Qraizer‘а!

Славян

Сообщ. #5 , 21.01.23, 15:52

Цитата grgdvo @ 21.01.23, 14:36 никаких условий нет?? Все линейно?? Да, всё именно банально так. Добавлено 21.01.23, 15:56 А, тьфу, всё понял! Это, как и написал Dushevny, оттого, что в x[0] то что-то кладётся по условия, а не всегда! int *x; … x = new int[1000]; … if( … ) x[0] = …; if( … ) { … }else {   int xMinMax[2];   xMinMax[0] = xMinMax[1] = x[0]; // здесь подчёркивает и пишет ‘c6001: Использование неинициализированной памяти «*x»‘   … } Добавлено 21.01.23, 15:59 Цитата grgdvo @ 21.01.23, 14:36 Вокруг x = new int[1000]; никаких условий нет?? Получается, ошибся я, — есть условие ‘вокруг’=после. Виноват-с…

Majestio	Сообщ. #6 , 21.01.23, 16:01
Злое Солнце Рейтинг (т): 10	Славян, на какую именно строку идет «ругня»? Ты выдаешь такие «крохи» инфы, что просто приходится ломать спинной моск в попытках «угадать» Ну что может быть проще привести весь проблемный код, и вывести все сообщения об ошибках и предупреждениях в первозданном виде? Не, без комментов далее … Добавлено 21.01.23, 16:04 ADD: И даже после решения вопроса я не отказываюсь от своих «фу» и «фи»

Dushevny

Сообщ. #7 , 21.01.23, 17:11

Member Рейтинг (т): 16

Цитата Majestio @ 21.01.23, 15:01 Что-то мне казалось, что для POD-типов нет ни конструкторов (не путать с аллокаторами), не их вызовов, ни по-умолчанию и ваапще никак! Что нет, что пустой и выкинутый оптимизатором по причине своей пустоты — для выходного кода результат одинаков. Может и есть исключение для POD-типов в стандарте — не помню, мне проще для себя для однообразия считать что конструктор есть, но пустой и потому соптимизированный. Сообщение отредактировано: Dushevny — 21.01.23, 17:16

Славян

Сообщ. #8 , 21.01.23, 17:17

Цитата Majestio @ 21.01.23, 16:01 на какую именно строку идет «ругня»? Строка приведена. Она вся подчёркивается волнистой. Но суть то вся понята, ибо действительно x[0] то ли инициализировался, то ли нет — компилятор не знает, и вот на это использование и идёт ругань. Всё действительно просто. Это как тривиальное: int a; int b = a; Добавлено 21.01.23, 17:23 Ну, чуть полнее, так: int *x, k=0; … x = new int[1000]; … if( … ) x[k++] = …; if( !k ) {   … }else {   int xMinMax[2];   xMinMax[0] = xMinMax[1] = x[0]; // здесь подчёркивает и пишет ‘c6001: Использование неинициализированной памяти «*x»‘   … } Потому мне то вот понятно, что использован будет инициализированный элемент x[0], а машине — неведомо сие…

Majestio	Сообщ. #9 , 21.01.23, 17:41
Злое Солнце Рейтинг (т): 10	Цитата Славян @ 21.01.23, 17:17 Она вся подчёркивается волнистой. Ну я на форуме обычно на все смотрю корпускулярно — не видны эти ваши красные волны! Добавлено 21.01.23, 17:43 Цитата Dushevny @ 21.01.23, 17:11 Что нет, что пустой и выкинутый оптимизатором по причине своей пустоты — для выходного кода результат одинаков. Не не не — «точность — вежливость королей». Это нужно выяснить.

Qraizer

Сообщ. #10 , 21.01.23, 18:17

Moderator Рейтинг (т): 520

Ну конечно нет никаких конструкторов у POD. Но по факту это ничего не меняет. В Стандарте определение объектов без инициализаторов называется default initialization и выполняется по-разному для классов и не-классов. Для классов вызывается конструктор по умолчанию. Если он не предоставлен программистом, он может быть сгенерирован компилятором. Если он не может быть сгенерирован, ошибка; если может, то он работает по тем же правилам инициализации для всех агрегированных объектов, т.е. все базовые объекты и поля инициализирует default initialization. Аналогично для массивов: default initialization для каждого элемента. Для не-классов ничего не выполняется. Это оставляет их в неизменном виде. Указатели являются не-классами. Ссылки и константные объекты не могут быть default initialization, это ошибка. Для агрегатов, содержащих в себе объекты этого типа, конструктор не может быть сгенерирован. Но в Стандарте есть ещё такая штука, как zero initialization. Она не применяется к автоматическим и динамическим объектам, но если применяется, то до любой другой инициализации, в частности и default initialization. Т.к. для классов default initialization вполне себе инициализатор, хоть и зачастую неявный, то работу zero initialization можно увидеть только на статических и локальных в потоках объектах не-классах. И да, она забивает объект нулями. За исключением указателей, которые ставятся в nullptr. (Это на случай, если у вас nullptr не равен побитово целочисленному нулю . Ну а вдруг.) И да, включая pad-ы между полями агрегатов. А, ещё для ссылок есть исключение: zero initialization для них не выполняется, но т.к. они обязаны быть value initialized, то этого не видно. Сообщение отредактировано: Qraizer — 21.01.23, 18:19

Majestio

Сообщ. #11 , 21.01.23, 18:20

Злое Солнце Рейтинг (т): 10

Цитата Qraizer @ 21.01.23, 18:17 Ну конечно нет никаких конструкторов у POD. Но по факту это ничего не меняет. В Стандарте определение объектов без инициализаторов называется default initialization и выполняется по-разному для классов и не-классов. Для классов вызывается конструктор по умолчанию. Если он не предоставлен программистом, он может быть сгенерирован компилятором. Если он не может быть сгенерирован, ошибка; если может, то он работает по тем же правилам инициализации для всех агрегированных объектов, т.е. все базовые объекты и поля инициализирует default initialization. Аналогично для массивов: default initialization для каждого элемента. Для не-классов ничего не выполняется. Это оставляет их в неизменном виде. Указатели являются не-классами. Ссылки и константные объекты не могут быть default initialization, это ошибка. Для агрегатов, содержащих в себе объекты этого типа, конструктор не может быть сгенерирован. Но в Стандарте есть ещё такая штука, как zero initialization. Она не применяется к автоматическим и динамическим объектам, но если применяется, то до любой другой инициализации, в частности и default initialization. Т.к. для классов default initialization вполне себе инициализатор, хоть и зачастую неявный, то работу zero initialization можно увидеть только на статических и локальных в потоках объектах не-классах. И да, она забивает объект нулями. За исключением указателей, которые ставятся в nullptr. (Это на случай, если у вас nullptr не равен побитово целочисленному нулю . Ну а вдруг.) И да, включая pad-ы между полями агрегатов. А, ещё для ссылок есть исключение: zero initialization для них не выполняется, но т.к. они обязаны быть value initialized, то этого не видно. ЧТД, RTFM

0 пользователей читают эту тему (0 гостей и 0 скрытых пользователей)

0 пользователей:

• Предыдущая тема
• C/C++: Общие вопросы
• Следующая тема

[ Script execution time: 0,0629 ]   [ 16 queries used ]   [ Generated: 10.02.23, 10:10 GMT ]  

Если вы пишете код на языке C или C++, поиск и устранение ошибок работы с памятью, таких, как утечки, выход за границы массива или обращение к неинициализированной памяти, могут доставить немало хлопот. Существует по крайней мере два инструмента для решения этих проблем — Valgrind (не путать с Vagrant!) и Clang’овский MemorySanitizer. Последний работает исключительно под Linux и показал себя несколько сырым и не слишком гибким инструментом, поэтому поговорим о Valgrind. Он довольно гибок и работает везде. Кроме того, в отличие от MemorySanitizer, Valgrind может находить неинициализированные данные с точностью до одного бита. Из недостатков Valgrind стоит отметить сравнительно низкую скорость работы.

Простой пример

Перейдем сразу к делу и проверим работу Valgrind на такой программе:

Компилируем с отладочными символами и запускаем ее под Valgrind:

Результат:

Видим, что память утекла. Запускаем с --leak-check=full:

Теперь раскомментируем вызов free и уберем инициализацию переменной delta. Посмотрим, увидит ли Valgrind обращение к неинициализированной памяти:

Видит. Запустим с --track-origins=yes чтобы найти, откуда именно пришла неинициализированная переменаая:

Как видите, Valgrind нашел место объявления неинициализированной переменой с точностью до имени файла и номера строчки.

Теперь исправим все ошибки:

Ну разве не красота?

Пример посложнее — запускаем PostgreSQL под Valgrind

Рассмотрим, как происходит запуск под Valgrind больших программ, например, PostgreSQL. Работа с памятью в этой РСУБД устроена особым образом. Например, в ней используются иерархические пулы памяти (memory contexts). Для понимания всего этого хозяйства Valgrind’у нужны подсказки. Чтобы такие подсказки появились, нужно раскомментировать строчку:

… в файле src/include/pg_config_manual.h, после чего полностью пересобрать PostgreSQL. Затем запуск под Valgrind осуществляется как-то так:

Полный пример вы найдете в файле valgrind.sh из этого репозитория на GitHub.

Обратите внимание на флаг --leak-check=no. Даже с упомянутыми подсказками Valgrind все равно не подходит для поиска утечек памяти в PostgreSQL. Он попросту будет генерировать слишком много ложных сообщений об ошибках. Поэтому здесь Valgrind используется только для поиска обращений к неинициализированной памяти.

Флаг --trace-children=yes в приведенной выше команде, как несложно догадаться, говорит Valgrind’у цепляться к процессам-потомкам.

Еще стоит отметить флаг --suppressions, который задает файл с описанием ошибок, которые следует игнорировать, а также флаг --gen-suppressions=all, который в случае возникновения ошибок генерирует строки, которые можно добавить в этот самый файл для игнорирования ошибок. Кстати, в файле можно использовать wildcards, в стиле:

В зависимости от используемых флагов, make installcheck под Valgrind’ом на моем ноутбуке выполняется от получаса до часа. Для сравнения, без Valgrind’а соответствующий прогон тестов занимает порядка 3.5 минут. Отсюда можно сделать вывод, что программа под Valgrind выполняется в 10-20 раз медленнее.

Использование Valgrind совместно с GDB

Посмотрев на приведенные выше отчеты Valgrind’а об ошибках, можно заметить, что в определенном смысле они недостаточно информативны. В частности, в них нет имен переменных и информации о том, какие конкретно данные в них лежали на момент возникновения ошибки. Решается эта проблема запуском Valgrind’а с флагами:

Эти флаги говорят Valgrind остановить процесс и запустить gdb-сервер после возникновения первой ошибки. Можно указать и --vgdb-error=0, чтобы подключиться к процессу отладчиком сразу после его запуска. Однако это может быть плохой идеей, если вы также указали --trace-children=yes и при этом программа создает множество дочерних процессов.

При возникновении ошибки Valgrind напишет:

После этого, чтобы подключиться к процессу при помощи GDB, говорим:

… и уже в отладчике:

Из интересных дополнительных команд доступны следующие. Посмотреть список утечек:

Узнать, кто ссылается на память:

Проверка инициализированности памяти (0 — бит инициализирован, 1 — не инициализирован, _ — not addressable):

Прочее:

Дальше отлаживаем, как обычно. Например, говорим continue. Как только произойдет следующая ошибка, программа снова остановится по брейкпоинту. Можно смотреть значения переменных, перемещаться между фреймами стека, ставить собственные брейкпоинты, и так далее.

Заключение

К сожалению, в рамках одного поста невозможно рассмотреть абсолютно все возможности Valgrind. Например, в него входят инструменты Callgrind и Massif, предназначенные для поиска узких мест в коде и профилирования памяти соответственно. Эти инструменты я не рассматриваю, так как для решения названных задач предпочитаю использовать perf и Heaptrack. Также существует инструмент Helgrind, предназначенный для поиска гонок. Его изучение я вынужден оставить вам в качестве упражнения.

Как видите, пользоваться Valgrind крайне просто. Он, конечно, не идеален. Как уже отмечалось, Valgrind существенно замедляет выполнение программы. Кроме того, в нем случаются ложноположительные срабатывания. Однако последняя проблема решается составлением специфичного для вашего проекта файла подавления конкретных отчетов об ошибках. Так или иначе, если вы пишете на C/C++ и не прогоняете код под Valgrind хотя бы в Jenkins или TeamCity незадолго до релиза, вы явно делаете что-то не так!

А как вы ищете утечки и обращения к неинициализированной памяти?

Метки: C/C++, Отладка.