Удаление массива

[Lex]

Проблема в следующем.
Есть dll созданная с использованием статической библиотеки MFC

в ней есть функция

Код:

PMYSTRUCT FAR PASCAL EXPORT GetMyStruct()
{
    AFX_MANAGE_STATE(AfxGetStaticModuleState());

    PMYSTRUCT pm;
    pm = new MYSTRUCT[20];

// заполняем pm

    return pm;
}

В основном модуле делаем следующее:

Код:

    if (GetMyStruct == NULL) return;  // dll подгружается динамически

    PMYSTRUCT pm = GetMyStruct();
//  обрабатываем pm
   delete[] pm;

при выполнении delete[] pm выскакивает ASSERT, что указатель неправильный. Где зарылась бага?

[GlukSoft]

Lex, а указатель изначально возвращается правильный?
Есть подозрения, что проблема в том, что основной модуль не знает сколько было выделено памяти в dll.

[Алексей++]

PMYSTRUCT pm;
    pm = new MYSTRUCT[20];

а разве pm не должен быть указателем?

PMYSTRUCT *pm;
    pm = new MYSTRUCT[20];

или это тип какой-то специальный...

[GlukSoft]

Алексей1153, память выделяется для MYSTRUCT, а присвоение идет типу PMYSTRUCT, судя по префиксу P тип определен как указатель на MYSTRUCT типа typedef MYSTRUCT* PMYSTRUCT.

[Lex]

судя по префиксу P тип определен как указатель на MYSTRUCT типа typedef MYSTRUCT* PMYSTRUCT.

Угу так оно и есть, сорри что забыл написасть.

Указатель возвращается правильный. Эта моя структура нормально обрабатывается. И если закоментировать delete[] pm , то программа работает, но оставляет после себя неосвобожденную память, что не есть гуд. Вопрос собственно такой, как правильно удалить такой указатель из основной програмы.

[SlavaI]

А MFC operator new[](size_t size) как-нибудь хитро не переопределяет. Если она его переопределила, то она наверно как-то по своему оббивает начало и конец выделенной памяти. Если мое предположение верно- то надо использовать operator delete[] из MFC.

[RXL]

Удаление через delete[] вполне корректно. Пробовал проверить на gcc с промежуточным выводом в asm-е: new получает в качестве параметра _размер_требуемомой_памяти_ (20*sizeof(MYSTRUCT)), а delete[] просто удаляет его (передаваемый параметер один - указатель). Сведения о размере выделенной памяти сохраняет runtime библиотека и динамическая библиотека здесь не помеха.

Попробуй сделать тот же самое в пределах одного модуля.

[Lex]

Попробуй сделать тот же самое в пределах одного модуля.

В пределах одного модуля все работает и не ругается.
Как мне кажется тут есть какаята макрософтовская фича, о которой надо знать, когда модуль проектируешь.

[SlavaI]

Как мне кажется тут есть какаята макрософтовская фича, о которой надо знать, когда модуль проектируешь.

А dll и прога ее вызывающая собраны с использованием MFC?

[GlukSoft]

Lex, а если попробовать так:
for (i = 0; i < 20; i++)
delete pm++;

[SlavaI]

for (i = 0; i < 20; i++)
delete pm++;

Ну это уж совсем. Офигительно неправильная операция(извини за резкость- но это ужасная ошибка, делать так как ты предложил).
 Никогда так делать нельзя- перед началом выделенной области и после ее конца находится служебная инфа, в таком случае в роли этой инфы выступят элементы массива. Выделил operator new[](...) - удаляй operator delete[](void*).

[Lex]

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

Код:

pm = (PMYSTRUCT)malloc(20 * sizeof(MYSTRUCT));

но при вызове free(pm) все равно возникнет ошибка

[Lex]

Нда, проблема решилась заменой new/delete на
HeapAlloc(GetProcessHeap(), .....)/HeapFree(GetProcessHeap(), .....)

Странно. Исходя из MSDN malloc и new, по идее должны использовать эти же функции.

[SlavaI]

Нда, проблема решилась заменой new/delete на
HeapAlloc(GetProcessHeap(), .....)/HeapFree(GetProcessHeap(), .....)

Странно. Исходя из MSDN malloc и new, по идее должны использовать эти же функции.

А ты мои посты выше читал?
Вероятно в дебажной версии MFC заменен operator new[]() и operator delete[](). И если dll собрана с MFC в дебажном варианте, а exe- нет, то в этом причина.
Проблема- в несоответствии new и delete(один из MFC, другой из CRT), они помимо HeapAlloc(GetProcessHeap(), .....)/HeapFree(GetProcessHeap(), .....)  вероятно еще свои заголовки использовали.

[Lex]

SlavaI, все в дебажном варианте. Про переопределение это я знаю, но в все равно должно вызываться HeapAlloc() (хотя я могу быть и не прав). Всякие GlobalAlloc LocalAlloc в Win32 согласно MSDN в итоге вызывают HeapAlloc(). и это сделано для совместимости с 16-битными приложениями.
Единственный возможный вариант это то, что MFC использует разные кучи для каждого модуля. Пойду покопаюсь в исходниках MFC.

[SlavaI]

Пойду покопаюсь в исходниках MFC

И охота тебе в этом копаться . Как ты дошел до такой жизни- использовать MFC? Проект что ли старый очень?

[Lex]

Как ты дошел до такой жизни- использовать MFC? Проект что ли старый очень?

Угу ему ужо лет 5 будет, а то и больше.
В общем в MFC они просто _malloc_dbg() /_free_dbg() вызывают
А те в свою очередь уже занимаются вызовом HeapAlloc()/HeapFree().

Слава, кстати, я менял new на malloc() та же фигня. Ты случаем не в курсе, как эти кучи распределяются по загруженным модулям и основной программе?

[Mouse]

У меня давно было что-то подобное. У меня дело было вот в чем: я пытался удалять указатель дважды, т.е. (на данном примере) первый раз в GetMyStruct(), а второй раз уже в вызывающем модуле непосредственно delete'ом. Проверь эту тему. Конкретно в чем дело, я тогда не копал - исправил и забыл...
Просто смотри, Lex: область видимости переменной pm - функция GetMyStruct(). А ведь по выходе указатель удаляется автоматически! По крайней мере так должно быть. Просто по идее GetMyStruct() возвращает указатель, который по выходе из функции уничтожается, т.е. система считает его = NULL. Слушай, а в основном модуле обработка pm шла корректно?

[Lex]

Archangel Я же описал проблема имено в том, что new в dll и delete в програме пытаются использовать разные кучи, как я понял. Меня сейчас интересует приведение этих куч к единому знаменателю, чтобы можно было пользовать new/delete. Самому подменять стандартный new/delete не сильно хочется

[NetRaider]

Я же описал проблема имено в том, что new в dll и delete в програме пытаются использовать разные кучи, как я понял. Меня сейчас интересует приведение этих куч к единому знаменателю, чтобы можно было пользовать new/delete. Самому подменять стандартный new/delete не сильно хочется

Попробуй выставить у обоих проектов одинаковые run-time library.
Или нужно экспортировать из DLL функции работы с памятью DllAlloc(), DllFree(). И использовать только их для выделения памяти при работе с этой DLL.

Кстати кучи не разные, - она одна. Проблема в том что CRT сохраняет информацию о выделенной памити в своих внутренних структурах, - а вот их может быть несколько - по одной для каждой копии библиотеки, статически прилинкованной к EXE или DLL.

[little]

У меня подобная проблема была, и я спрашивал об этом на форуме, но тогда пришли к мнению, что я что-то где упустил. Динамически созданный класс возвращал указатель на выделенный массив, затем класс уничтожался. И начинались такие танцы с бубнами... память то выделялась, то нет. Заказываешь один объем - выделяется, заказываешь меньший(!) - вылетает.

[Lex]

NetRaider, куч несколько. Точнее там все намного хитрее. Достаточно большая пляска идет с выделением виртуальных страниц. И вся эта инфа, кстати, цепляется к выделеному блоку.

[NetRaider]

Достаточно большая пляска идет с выделением виртуальных страниц. И вся эта инфа, кстати, цепляется к выделеному блоку.

Цепляется...  И сохраняется в списке, состоящем из экземпляров _CrtMemBlockHeader. А экземпляров этих списков может быть несколько. Отсюда и проблемы - выделил кусок память - информация о нем сохранилась в списке. Удалять надо и этого же списка, а не из другого.

[RXL]

На основе всего сказанного, получается что для отладки можно включить в динамическую библиотеку ф-ии удаления и через них освобождать занятую библиотекой память.
Пример:

Код:

void do_delete(void *p) { delete p; }
void do_delete_array(void *p) { delete[] p; }

[Anonymous]

Lex,  если проблема ещё не решена, то:

попробуй определить глобальную переменную  и экспортируй её из dll

#define MYDLL __declspec(dllexport)

extern MYDLL PMYSTRUCT g_pMyStruct;

потом в функции:

g_pMyStruct = new MYSTRUCT[20];

а в основном модуле пользуйся g_pMyStruct.


Джон

[Lex]

Джон задачу решил.
А в товоем примере все равно вылезет ошибка при вызове delete, т.к. память выделяется в одном блоке(принадлежащем dll) а удаятся из другого блока(принадлежащего программе).

[Boris Tkach]

Насколько я понимаю так делать нельзя.
Чтобы это работало можно переопределить new, delete и заставить их все работать через одно место во всем проекте.
Или добавлять в dll метод для освобождения полученного указателя.
Кстати, такая же проблема будет если передать объект (например std::vector) в dll и там его изменить (добавить элементы).
Правда если при сборке указываются одинаковые run-time библиотеки, совпадают ключи отладки и т.д. - то будет работать (иногда).

[Lex]

Boris Tkach, понятно, что нельзя возникает вопрос почему?

[Джон]

Lex,  Слушай, я так (или почти так) делал - работало и работает уже года два поэтому и тебе советовал. А вот тепрь сомневатся начал - чую, что-то не то. Правда соблюдены условия:

при сборке указываются одинаковые run-time библиотеки, совпадают ключи отладки и т.д.

В общем если время и желание есть  - я могу код откопать посмотреть? Почему оно работает. Схема такая была: был экзешник, была длл статическая,  и в неё загружаемые динамически  другие длл. Короче, общий класс был Порт, а в зависимости от того какие у тебя порты проинсталлены - загружались СОМ, LPT USB и тд дллки. Соответствующие объекты создавались с new в длл.

Или я не правильно себе картину представляю и речь идёт о другом. Да, это не были библиотеки расширения MFC, а простые Win32 API. Хотя такое я тоже где-то делал из длл экспортировал диалоги. Но может там по-другому было (не уверен).

[Lex]

Джон, понял ты правильно. И задача у меня похожая. У меня есть основное окно и куча dll, которые описывают разные типы приемников, загружаемые динамически.

Проблему я решил, но осталось недопонимание причин проблемы.
Мое видение было таково, что все dll грузятся в адресное пространство процесса и память всегда выделяется в адресном пространстве процесса.
Из этого я делал вывод, что все равно где вызывать new и delete(также как malloc и free). Оказалось, что это не так, по крайней мере не всегда.
Вот и хочется понять почему.