При поиске утечек памяти полуаю следующее сообщение:

Detected memory leaks!
Dumping objects ->
{965} normal block at 0x00376860, 0 bytes long.
 Data: <> Xю
Object dump complete.

Что это за утечка длинной 0 байт?
Также непонятно почему он его определяет как утечку, при проверке было выяснено что delete для данного блока вызывается всегда.

"Alco" <60379@users.rsdn.ru> wrote in message news:2232557@news.rsdn.ru...
> При поиске утечек памяти полуаю следующее сообщение:
>

> Detected memory leaks!
> Dumping objects ->
> {965} normal block at 0x00376860, 0 bytes long.
> Data: <> Xю
> Object dump complete.
>

> Что это за утечка длинной 0 байт?

Очевидно, был выделен блок памяти длиной 0 байт.

> Также непонятно почему он его определяет как утечку, при проверке было выяснено что delete для данного блока вызывается всегда.

Возможно, утечки дампятся раньше чем этот блок памяти удаляется.

Здравствуйте, Alco, Вы писали:

A>При поиске утечек памяти полуаю следующее сообщение:
A>

A>Detected memory leaks!
A>Dumping objects ->
A>{965} normal block at 0x00376860, 0 bytes long.
A> Data: <> Xю
A>Object dump complete.
A>

A>Что это за утечка длинной 0 байт?
A>Также непонятно почему он его определяет как утечку, при проверке было выяснено что delete для данного блока вызывается всегда.


Без кода, особенно в районе new диагноз затруднителен.

Здравствуйте, Sergey, Вы писали:

S>Очевидно, был выделен блок памяти длиной 0 байт.

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

S>Возможно, утечки дампятся раньше чем этот блок памяти удаляется.

Утечки дампятся при завершении программы (_CrtSetDbgFlag(_CrtSetDbgFlag(_CRTDBG_REPORT_FLAG) | _CRTDBG_CHECK_ALWAYS_DF | _CRTDBG_LEAK_CHECK_DF))

Здравствуйте, aset, Вы писали:

A>Без кода, особенно в районе new диагноз затруднителен.

...
unsigned char *data = 0;
unsigned long dataLength; 
int unpackRes = obj->thisObj->UnpackData(receiveBuf + 2, dataLen + 7, &data, &dataLength);
            
if(unpackRes == PACKET_PARSING_SUCCESSFUL)
{
unsigned char *data = 0;
unsigned long dataLength; 
int unpackRes = obj->thisObj->UnpackData(receiveBuf + 2, dataLen + 7, &data, &dataLength);

if(unpackRes == PACKET_PARSING_SUCCESSFUL)
{
    PackInfo pInf;
    pInf.dataSize = dataLength;
    pInf.data = new unsigned char [dataLength];
    memcpy(pInf.data, data, dataLength);
    pInf.format = format;
    pInf.idMB = obj->idMB;
    if(pInf.idMB == 0)
    {
        pInf.nBind = obj->nbindId;
    }

    ATAutoSynhronize<ATCriticalSection> acs(&obj->thisObj->m_recvPackListCS);

    acs.Lock();
    obj->thisObj->m_receivedPack.push_back(pInf);
    acs.Unlock();

    if(!SetEvent(obj->thisObj->m_evRecvPackPlaced))
    {
        _ASSERT(false);
        return;
    }
}
else
{
    _ASSERT(false);
}

delete [] data;
...

Внутри obj->thisObj->UnpackData(...) выделяется память, ее адрес записывается в data, в итоге этот блок определяется как утечка.
Выделение происходит обычным образом, далее в блок просто копируются данные, никаких других манипуляций с блоком не происходит.

*data = new unsigned char[*dataLength];
...
memcpy(*data, decryptData, *dataLength);

Здравствуйте, Alco, Вы писали:

A>Здравствуйте, Sergey, Вы писали:

S>>Очевидно, был выделен блок памяти длиной 0 байт.

A>В приципе такое возможно, но маловероятно, не могу это проверить, проблема в том что ситуация не повторяется, причем код не менялся.

Проверил, специально вставил _ASSERT на размер блока, он не сработал, а ситуация с ликом повторилась

> S>Очевидно, был выделен блок памяти длиной 0 байт.
>
> В приципе такое возможно, но маловероятно, не могу это проверить,

Это не маловероятно, это стопудово

> проблема в том что ситуация не повторяется, причем код не менялся.

Вполне возможно, что оно просто от входных данных зависит.

>
> S>Возможно, утечки дампятся раньше чем этот блок памяти удаляется.
>
> Утечки дампятся при завершении программы (_CrtSetDbgFlag(_CrtSetDbgFlag(_CRTDBG_REPORT_FLAG) | _CRTDBG_CHECK_ALWAYS_DF | _CRTDBG_LEAK_CHECK_DF))

Тем не менее, на VC 6 такая ситуация встречалась регулярно. На восьмерке пока не видел. Проверить очень просто — воткнуть точку останова в функцию _CrtDumpMemoryLeaks и в тот кусок кода, который удаляет якобы текущий объект.

Здравствуйте, Alco, Вы писали:

A>Здравствуйте, aset, Вы писали:

A>>Без кода, особенно в районе new диагноз затруднителен.
A>

A>...
A>unsigned char *data = 0;
A>unsigned long dataLength; 
A>int unpackRes = obj->thisObj->UnpackData(receiveBuf + 2, dataLen + 7, &data, &dataLength);
A>if(unpackRes == PACKET_PARSING_SUCCESSFUL)
A>{
A>  unsigned char *data = 0;
A>  unsigned long dataLength; 
A>  int unpackRes = obj->thisObj->UnpackData(receiveBuf + 2, dataLen + 7, &data, &dataLength);
A>  ...
A>}
A>delete [] data;
A>...
A>

A>Внутри obj->thisObj->UnpackData(...) выделяется память, ее адрес записывается в data, в итоге этот блок определяется как утечка.
A>Выделение происходит обычным образом, далее в блок просто копируются данные, никаких других манипуляций с блоком не происходит.

Ну так а где освобождение памяти-то? Последенее 'delete' работает с внешней 'data' и освобождает память, пришедшую из первого вызова 'UnpackData'. А ты еще и внутреннюю 'data' объявил, передаваемую во второй вызов 'UnpackData'. Эту память-то кто будет освобождать?

Не надо без крайней необходимости объявлять переменные со одинаковыми именами в вложенных областях видимости.

P.S. В программистком языке, если утечка составляет всего 0 байт, слово "длина" пишется вообще без букв 'н' — "длиа". Если утечка больше нуля, то тогда "длина". А вот "длинна" — это только когда больше терабайта утекло...

Посмотрев внимательнее, я разглядел, что 'delete[]' относится именно к внутреннему 'UnpackData'. Тогда, соответственно, вопрос: а где освобождение памяти для внешнего 'UnpackData'? В приведенном куске кода его не видно.

Здравствуйте, Андрей Тарасевич, Вы писали:

АТ>Посмотрев внимательнее, я разглядел, что 'delete[]' относится именно к внутреннему 'UnpackData'. Тогда, соответственно, вопрос: а где освобождение памяти для внешнего 'UnpackData'? В приведенном куске кода его не видно.
Узвиняйте, криво запостил, должно быть так:

unsigned char *data = 0;
unsigned long dataLength; 
int unpackRes = obj->thisObj->UnpackData(receiveBuf + 2, dataLen + 7, &data, &dataLength);

if(unpackRes == PACKET_PARSING_SUCCESSFUL)
{
    PackInfo pInf;
    pInf.dataSize = dataLength;
    pInf.data = new unsigned char [dataLength];
    memcpy(pInf.data, data, dataLength);
    pInf.format = format;
    pInf.idMB = obj->idMB;
    if(pInf.idMB == 0)
    {
        pInf.nBind = obj->nbindId;
    }

    ATAutoSynhronize<ATCriticalSection> acs(&obj->thisObj->m_recvPackListCS);

    acs.Lock();
    obj->thisObj->m_receivedPack.push_back(pInf);
    acs.Unlock();

    if(!SetEvent(obj->thisObj->m_evRecvPackPlaced))
    {
        _ASSERT(false);
        return;
    }
}
else
{
    _ASSERT(false);
}

delete [] data;

Alco wrote:

> pInf.data = new unsigned char [dataLength];

А зачем new/delete? Чем std::vector не устраивает?
Потом,
> Dumping objects ->
> {965} normal block at 0x00376860, 0 bytes long.
Если 965 не меняется, или меняется предсказуемо, то можно сделать "_CrtSetBreakAlloc(965)" и посмотреть, где блок
выделяется.

Здравствуйте, kan, Вы писали:

kan>А зачем new/delete? Чем std::vector не устраивает?
Есть свои причины
kan>Потом,
>> Dumping objects ->
>> {965} normal block at 0x00376860, 0 bytes long.
kan>Если 965 не меняется, или меняется предсказуемо, то можно сделать "_CrtSetBreakAlloc(965)" и посмотреть, где блок
kan>выделяется.
Ну я собственно так и сделал. Правда номера блоков всегда разные, т.к. данный кусок вызывается много раз, но при установке бряки на любой из номеров попадаю в одно и то же место.

Alco wrote:

> Ну я собственно так и сделал. Правда номера блоков всегда разные, т.к.
> данный кусок вызывается много раз, но при установке бряки на любой из
> номеров попадаю в одно и то же место.
И? Вызывается delete для этого блока под отладчиком (пройдись пошагово)?
Может он до этого оператора не доходит — return или исключение или ещё чего.
Вариант хуже — если где-то память портится или ещё какое Undefined Behavior, тогда довольно сложно искать.

Здравствуйте, kan, Вы писали:

kan>И? Вызывается delete для этого блока под отладчиком (пройдись пошагово)?
kan>Может он до этого оператора не доходит — return или исключение или ещё чего.
kan>Вариант хуже — если где-то память портится или ещё какое Undefined Behavior, тогда довольно сложно искать.
Блин да проверил я это перед тем как постить сюда. Утечка при этом все равно детектируется, при чем с длиной 0 байт, была введена проверка на длину блока, она всегда больше нуля. Собственно меня это не сильно волнует, но было бы неплохо понять из-за чего такое происходит. Да, забыл сказать, этот кусок может одновременно работать в нескольких потоках, возможно это тоже как-то влияет.

Alco wrote:

> kan>И? Вызывается delete для этого блока под отладчиком (пройдись пошагово)?
> kan>Может он до этого оператора не доходит — return или исключение или
> ещё чего.
> kan>Вариант хуже — если где-то память портится или ещё какое Undefined
> Behavior, тогда довольно сложно искать.
> Блин да проверил я это перед тем как постить сюда. Утечка при этом все
> равно детектируется, при чем с длиной 0 байт, была введена проверка на
> длину блока, она всегда больше нуля. Собственно меня это не сильно
> волнует, но было бы неплохо понять из-за чего такое происходит. Да,
> забыл сказать, этот кусок может одновременно работать в нескольких
> потоках, возможно это тоже как-то влияет.
Может кучи разные используются?
Приведи минимальную, но полную программу, демонстрирующую проблему.
В общем трудно сказать, попробуй какой-нибудь тулзой пройтись типа Rational Purify.