Heap/Stack corruption on DLL call

I am trying to use a Visual Studio 2008 SP1 created dll (with Common Language Runtime Support enabled) within Codeblocks (which uses GCC under mingw). Some of the arguments that are being passed to the dll have been dynamically allocated by the calling function. My question is:

"Can the arguments being passed to a dll reside on the heap of the calling function. Is it safe to do this?"

On return from dll the stack of the calling function gets corrupted and on trying to access those, I get a SIGTRAP within codeblocks when I try to debug this problem.

What could be the reason for this?

The prototype of the dll function goes like this:

int __cdecl myTesseractOCR(myOCRData* labels_for_ocr);

myOCRDaata definition is as shown below:

typedef struct __ocr_data
{
    char* arr_image       [NUMOBJ_LIMIT_H开发者_JS百科IGH];
    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 points to data which resides on the calling function's heap where as all the other members of the above structure reside on the stack of the calling function. All these members residing on the stack get corrupted and the program generates a SIGTRAP. I have seen such problems being discussed all across in various threads on stackoverflow but haven't got figured out a concrete solution yet.

---

I'd advise that you make your DLL interface as flat as possible; i.e. avoid passing structures, even if they are POD. Since you're using 2 different compilers this is particularly important. If you do decide to pass structures, make sure the packing of the structures is explicitly defined under both compilers.

---

It's perfectly reasonable for the DLL to access memory that resides on the calling applications heap. If you couldn't do that then DLLs would be essentially useless.

Your problem must lie elsewhere. Most likely your aren't quite setting up the parameters for the call to the DLL correctly.

---

Can you cross check the calling conventions flags for GCC and DLL convention VS2kSP1 CLR

---

The heap does not belong to a function. It's perfectly fine to allocate memory in a module and pass-it to another one just make sure that the module that allocated the memory is the one that free it.
A second source of troubles may be a different calling conversion. Specify a calling convention for all exported functions.