Правильное освобождение ссылочных полей объекта

[UltraPenguin]

Доброго времени суток!

После прогона проги через valgrind последний выдал множество ошибок такого рода:

Address 0x10835098 is 8 bytes inside a block of size 16 free'd
==26294==    at 0x4C279DC: operator delete(void*) (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==26294==    by 0x43674A: CReadWriteINIParam::~CReadWriteINIParam() (ReadWriteINIParam.cpp:59)

Конкретно ругается на строку:

Код:

delete settings;

Само поле settings объявлено так:

Код:

QSettings *settings;

И его инициализация происходит в конструкторе класса CReadWriteINIParam через оператор new.
Почему возникает ошибка обращения к освобожденной памяти, если единственное освобождение находится как раз в деструкторе класса?

Если закомментить строку с delete, ошибки пропадут, но возрастут утечки памяти судя по тому, что выдает все тот же valgrind.

Возможно я чего-то недоучил, прошу сильно не ругаться

Заранее спасибо!

[GreatSnake]

При создании settings parent задавался?

[UltraPenguin]

Нет не задавался. Честно говоря, забыл про него, теперь понятно как побороть утечку. Спасибо большое!
Получается если не задан родитель, то поле считается освобожденным к моменту вызова деструктора?

[GreatSnake]

Получается если не задан родитель, то поле считается освобожденным к моменту вызова деструктора?

С чего это вдруг?

[UltraPenguin]

ну откуда то ошибка об обращении к свободной памяти берется?

[_Bers]

ну откуда то ошибка об обращении к свободной памяти берется?

Телепаты в отпуске. Вы даже минимальный код иллюстрирующий проблему не привели.

1. В вашей ИДЕ сделайте "показать использование" на подозрительную переменную. И рассмотрите все места где создается, где меняется, где прибивается.

2. Если первое не помогло - используйте пошаговую отладку. Вам нужно воссоздать картину действия.

[UltraPenguin]

Телепаты в отпуске. Вы даже минимальный код иллюстрирующий проблему не привели.

Вроде как телепаты и не требовались. В первом посте, как мне кажется, все достаточно детально описано. Но если нужен минимальный иллюстрирующий код то пожалуйста:

Код:

class CReadWriteINIParam
{
    private:
        QSettings* settings;
}

CReadWriteINIParam::CReadWriteINIParam()
{
    settings = new QSettings(sFileININame, QSettings::IniFormat);
}

CReadWriteINIParam::~CReadWriteINIParam()
{
    if (settings != NULL)
        delete settings;
}

Не вижу как это может помочь прояснить ситуацию правда.
И как пошаговая отладка поможет в деле распознавания адресации к освобожденной памяти, если явного освобождения в коде нет (до вызова деструктора)

[UltraPenguin]

1. В вашей ИДЕ сделайте "показать использование" на подозрительную переменную. И рассмотрите все места где создается, где меняется, где прибивается.

2. Если первое не помогло - используйте пошаговую отладку. Вам нужно воссоздать картину действия.

- У меня не включается утюг марки М модели К. Втыкаю в розетку на 220, нажимаю сюда. Что не так?
- Не знаю, попробуйте заснять ваши действия на видео и покадрово все просмотрите еще раз. Вам нужно воссоздать картину действия.

 

Простите, не сдержался

[UltraPenguin]

При создании settings parent задавался?

Я что-то рано обрадовался по поводу возможности указать родителя. Родителем ведь может быть только класс QObject и его наследники! Неужели единственный способ не вызывать гнев valgrinda, это наследовать ненужный функционал QObject?

Хотя, конечно, можно просто закрыть глаза на данные строки valgrinda, память то чистится в любом случае...

[kambala]

зачем сеттингсам задавать родителя и создавать их в куче?

[sergek]

Интересная у вас тут беседа завязалась

Хотя, конечно, можно просто закрыть глаза на данные строки valgrinda, память то чистится в любом случае...

Не то слово - даже дважды:

Memcheck keeps track of the blocks allocated by your program with malloc/new, so it can know exactly whether or not the argument to free/delete is legitimate or not. Here, this test program has freed the same block twice. As with the illegal read/write errors, Memcheck attempts to make sense of the address freed. If, as here, the address is one which has previously been freed, you wil be told that -- making duplicate frees of the same block easy to spot. You will also get this message if you try to free a pointer that doesn't point to the start of a heap block.

А попробуйте закомментировать весь код, использующий созданный settings, кроме new/delete и прогнать через valgrind. Интересно, останется ошибка?

[_Bers]

Телепаты в отпуске. Вы даже минимальный код иллюстрирующий проблему не привели.

Вроде как телепаты и не требовались. В первом посте, как мне кажется, все достаточно детально описано. Но если нужен минимальный иллюстрирующий код то пожалуйста:

Код:

class CReadWriteINIParam
{
    private:
        QSettings* settings;
}

CReadWriteINIParam::CReadWriteINIParam()
{
    settings = new QSettings(sFileININame, QSettings::IniFormat);
}

CReadWriteINIParam::~CReadWriteINIParam()
{
    if (settings != NULL)
        delete settings;
}

Не вижу как это может помочь прояснить ситуацию правда.
И как пошаговая отладка поможет в деле распознавания адресации к освобожденной памяти, если явного освобождения в коде нет (до вызова деструктора)

Эта выдержка кода не иллюстрирует проблему. И вообще не соответствует действительности.
Непонятно для чего вы её привели вместо того, что бы привести выдержку реального кода.
Возможно вам просто лень решать собственную проблему.

По поводу пошаговой отладки: программист полагает. А программа располагает.
Очевидно, что в программе происходят действия, которых вы не ожидаете.

Пошаговая отладка может помочь понять, в чем именно вы ошиблись.

[_Bers]

Код:

CReadWriteINIParam::~CReadWriteINIParam()
{
    if (settings != NULL)
        delete settings;
}

Этот код вызывает сомнение.

1. Вы допускаете, что к моменту запуска диструктора setting может быть равен nullptr ?
Каким образом это может произойти?
 --- конструктор не захватил ресурс по указателю?
 --- существуют методы, которые могут освободить ресурс в процессе жизни экземпляра класс?

 Если второй пункт имеет место быть - стоит рассмотреть его внимательнее.

2. Нет ни одной причины проверять указатель на nullptr перед освобождением ресурса.

[UltraPenguin]

Эта выдержка кода не иллюстрирует проблему. И вообще не соответствует действительности.

Подождите, вы просили МИНИМАЛЬНЫЙ код иллюстрирующий проблему. Вот он.

Непонятно для чего вы её привели вместо того, что бы привести выдержку реального кода.

По разным соображениям, но в первую очередь из-за того, что его МНОГО.

По поводу пошаговой отладки: программист полагает. А программа располагает.
Очевидно, что в программе происходят действия, которых вы не ожидаете.
Пошаговая отладка может помочь понять, в чем именно вы ошиблись.

Ок, я вас понимаю. Но я спрашивал о том, КАК конкретно проверить указывает ли указатель (масло так маслит )  на свободную память или нет с помощью дебагера если в коде по ходу выполнения НЕТ delet'ов кроме указанного мной в минимальном примере кода?

UPD: я вот не в курсе как это сделать. Возможно, недоучил. Но скорее всего это просто никак не узнать)

[UltraPenguin]

А попробуйте закомментировать весь код, использующий созданный settings, кроме new/delete и прогнать через valgrind. Интересно, останется ошибка?

ок попробую, напишу результат