Повреждение кучи / стека при вызове DLL

Question

Я пытаюсь использовать DLL-библиотеку Visual Studio 2008 с пакетом обновления 1 (SP1) (с поддержкой поддержки общего языка) в Codeblocks (которая использует GCC под mingw). Некоторые из аргументов, передаваемых в dll, динамически распределяются вызывающей функцией. Мой вопрос:

"Могут ли аргументы, передаваемые в dll, находиться в куче вызывающей функции. Безопасно ли это делать?"

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

В чем может быть причина этого?

Прототип функции dll выглядит так:

int __cdecl myTesseractOCR(myOCRData* labels_for_ocr);

Определение myOCRDaata показано ниже:

typedef struct __ocr_data
{
    char* arr_image       [NUMOBJ_LIMIT_HIGH];
    int   start_x         [NUMOBJ_LIMIT_HIGH];
    int   start_y         [NUMOBJ_LIMIT_HIGH];
    int       width               [NUMOBJ_LIMIT_HIGH];
    int       height              [NUMOBJ_LIMIT_HIGH];
    int       widthstep           [NUMOBJ_LIMIT_HIGH]; 
    char      number_plate_buff   [2*NUMOBJ_LIMIT_HIGH];
    int       ocr_label_count;
} myOCRData;

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

Answer 1

Я бы посоветовал вам сделать свой интерфейс DLL как плоский , насколько это возможно; т.е. избегать прохождения структур, даже если они POD. Поскольку вы используете 2 разных компилятора, это особенно важно. Если вы решили передать структуры, убедитесь, что упаковка структур явно определена в обоих компиляторах.

Answer 2

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

Answer 3

Можете ли вы перепроверить флаги соглашений о вызовах для соглашений GCC и DLL VS2kSP1 CLR

Answer 4

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

Ваша проблема должна лежать в другом местеСкорее всего, вы не совсем правильно настраиваете параметры для вызова DLL.