Access violation calling C++ dll

I created c++ dll (using mingw) from code I wrote 开发者_JAVA技巧on linux (gcc), but somehow have difficulties using it in VC++. The dll basically exposes just one class, I created pure virtual interface for it and also factory function which creates the object (the only export) which looks like this:

extern "C" __declspec(dllexport) DeviceDriverApi* GetX5Driver(); 

I added extern "C" to prevent name mangling, dllexport is replaced by dllimport in actual code where I want to use the dll, DeviceDriverApi is the pure virtual interface.

Now I wrote simple code in VC++ which just call the factory function and then just tries to delete the pointer. It compiles without any problems but when I try to run it I get access violation error. If I try to call any method of the object I get access violation again.

When I compile the same code in MinGW (gcc) and use the same library, it runs without any problems. So there must be something (hehe, I guess many differences actually :)) between how VC++ code uses the library and gcc code.

Any ideas what?

Cheers, Tom

Edit: The code is:

    DeviceDriverApi* x5Driver = GetX5Driver();


if (x5Driver->isConnected())
    Console::WriteLine(L"Hello World");

delete x5Driver;

It's crashing when I try to call the method and when I try to delete the pointer as well. The object is created correctly though (the first line). There are some debug outputs when the object is created and I can see them before I get the access violation error.

• You're using one compiler (mingw) for the DLL, and another (VC++) for the calling code.
• You're calling a 'C' function, but returning a pointer to a C++ Object.

That will never work, because VTable layouts are almost guranteed to be incompatible. And, the DLL and app are probably using different memory managers, so you're doing new() with one and delete() with the other. Again, it just won't work.

For this to work the two compilers need to both support a standard ABI (Application Binary Interface). I don't think such a thing exists for Windows.

The best option is to expose all you DLL object methods and properties via C functions (including one to delete the object). You can the re-wrap into a C++ object on the calling end.

The two different compilers may be using different calling conventions. Try putting _cdecl before the function name in both the client code and the DLL code and recompiling both.

More info on calling conventions here: http://en.wikipedia.org/wiki/X86_calling_conventions

EDIT: The question was updated with more detail and it looks likely the problem is what Adrien Plisson describes at the end of his answer. You're creating an object in one module and freeing it in another, which is wrong.

(1) I suspect a calling covnention problem as well, though the simple suggestion by Leo doesn't seem to have helped.

Is isConnected virtual? It is possible that MinGW and VC++ use different implementations for a VTable, in which case, well, tough luck.

Try to see how far you get with the debugger: does it crash at the call, or the return? Do you arrive at invalid code? (If you know to read assembly, that usually helps a lot with these problems.)

Alternatively, add trace statements to the various methods, to see how far you get.

(2) For a public DLL interface, never free memory in the caller that was allocated by a callee (or vice versa). The DLL likely runs with a completely different heap, so the pointer is not known.

If you want to rely on that behavior, you need to make sure:

• Caller and Callee (i.e. DLL and main program, in your case) are compiled with the same version of the sam compiler
• for all supported compilers, you have configured the compile options to ensure caller and callee use the same shared runtime library state.

So the best way is to change your API to:

extern "C" __declspec(dllexport) DeviceDriverApi* GetX5Driver(); 
extern "C" __declspec(dllexport) void FreeDeviceDriver(DeviceDriverApi* driver); 

and, at caller site, wrap in some way (e.g. in a boost::intrusive_ptr).

try looking at the imported libraries from both your DLL and your client executable. (you can use the Dependency Viewer or dumpbin or any other tool you like). verify that both the DLL and the client code are using the same C++ runtime.

if it is not the case, you can indeed run into some issues since the way the memory is managed may be different between the 2, leading to a crash when freeing from one runtime a pointer allocated from another runtime.

if this is really your problem, try not destroying the pointer in your client executable, but rather declare and export a function in your DLL which will take care of destroying the pointer.