Question

I am creating a C++ Win32 dll with some global data. There is a std::map defined globally and there are exported functions in the dll that write data into the map (after acquiring a write lock, ofcourse).

My problem is, when I call the write function from inside the dll DllMain, it works without any problems. But when I load the dll from another program and call the function that writes data into the global map, it gives me this error:

WindowsError: exception: access violation reading 0x00000008

Is there something that can be done about this? The same function when called from DllMain has access to the global data in the dll, but when called from a different process, it doesn't have access to the global data. Please advice.

I am using the TDM-MinGW gcc 4.4.0 Compiler.

EDIT: Ok, I've figured out what the problem is, and thanks for the help guys, but the problem was not with a constructor issue or inability to have maps in global space, but an issue in the boost::python that I'm using. I had tested it, but since I was calling the dll from within python or maybe something, the urllib2 module wasn't getting loaded into the dll. Now I have to see how to fix it.

Was it helpful?

Solution

Looks like the constructor of std::map did not run yet when your code was called. Lifetime of global non-PODs in a Win32 DLL is pretty tricky, and I'm not certain as to how MinGW specifically handles it. But it may be that the way you're compiling the DLL, you've set your own function (DllMain?) as an entry point, and thus overrode the CRT initialization routine that calls constructors.

OTHER TIPS

A read error at such a low memory address generally means that you are trying to access a NULL pointer somewhere. Can you show your actual code?

You have to use shared memory, because the different processes have separate address spaces. I think you won't get std::map running. I would recommend using MapViewOfFile, CreateFileMapping, OpenFileMapping, ... and plain old data. Ask Google / MSDN.

Licensed under: CC-BY-SA with attribution
Not affiliated with StackOverflow
scroll top