Освобождение памяти основной программы изнутри dll давит в Visual studio 2010 - PullRequest
2 голосов
/ 21 мая 2011

Я столкнулся со странной проблемой при кодировании DLL-файла на C с помощью компилятора gcc, а затем попытался использовать его через MSVC и visual studio. DLL правильно компилируется и используется тестовыми программами, скомпилированными и связанными с gcc. Но когда я пытаюсь использовать .dll в Visual Studio, я получаю странное увлечение во время выполнения. Я выявил проблему и был бы признателен за ваш вклад в объяснение, почему это происходит.

В тестовой программе у нас есть функция, которая выделяет буфер, заполняет его некоторым образом (в зависимости от пользователя) и затем возвращает буфер. Пользователь должен реализовать это самостоятельно. Примерно так:

float* decode(void* data, int dataSize, int par1, int par2,int par3)
{ 

    //allocate the memory for the data
    float* d =  (float*)malloc(sizeof(float)*dataSize);

    //do something to populate the data here

    //return data
     return d;
}

У dll есть две функции, которые фактически получают указатель на функцию use-rmade и используют ее для получения буфера float *. Затем .dll использует эту функцию для создания и использования данных, а после использования освобождает их.

Примерно так:

void DLL_Func(void* data,unsigned int inputPN,float* (*decode)(void*,int,int,int,int))
{

    //use the user-made decode function
    float* nData = (*decode)(data,inputPN,par1,par2,par3);

    //do stuff here

    //before returning free the data buffer since it is no longer needed
    free(nData) //<--- Crushes the program only in Visual Studio
 }

Ну, я выделил проблему в этом free (). Работает нормально, если я использую мою dll из скомпилированной программы gcc, но скомпилированная программа MSVC в этот момент ломается и выдает следующее:

 Unhandled exception at 0x7714e1fe in vstudiotest.exe: 0xC0000005: Access violation reading location 0x1e6dca5e.

То, что я предполагаю, означает, что для компилятора MSVC то, что делает моя dll, запрещено. Это просто какая-то причудливость MSVC или GCC тоже должен сокрушить, но не вернется и не вернется в будущем и не мучит меня этой проблемой?

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

1 Ответ

3 голосов
/ 21 мая 2011

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

MSVC будет жаловаться, если вы попытаетесь установить связь с другими версиями MS CRT, но я предполагаю, что вы ссылаетесь на какую-то другую версию, о которой MSVC не знает.

...