0

I am having a very weird result with some code:

I am using boost.any (before was using void *) to return an address from a .dll in a .exe.

The dll has a function like this:

boost::any User::getNativeHandle() {
    return boost::any(pimpl_->adressOfObject_);
}

And my exe, code like this:

class SomeClass {   
public: 
   SomeClass(User & user) {
      scopedResource_([&](InternalType * s) {
        InternalTypeConstruct(..., user.getNativeHandle());
      }
   }
private:
   ScopedResource<InternalType> scopedResource_;
};

Facts and observations:

  • User object is created in the .exe, but it's a dll class.
  • The pointer printed from inside the .dll and outside of it has the same address, so it seems to be the correct object.
  • The printed value address is a multiple of 4 all the time, so it seems to be a valid address at least. 64-bit machine windows 8.
  • I had to remove some runtime libraries with /NODEFAULTLIB: ... but now it seems to be correctly setup.

  • The cast seems to be correct from boost.any back to my type in the .exe, since I made it fail before on purpose to make this sure.

  • The pointer returned from the User::getNativeHandle .dll is a type that is a pointer to a type from another library, a .lib library without any .dll, namely, a real static library.

It ends up crashing with SEH 0x00000005. My class User exposes the interface, and I also tried to dll export the Impl class for Pimpl, but it seems to do nothing.

Any idea? This bug is making me mad :).

Germán Diago
  • 7,473
  • 1
  • 36
  • 59
  • It looks like you're allocating memory within the DLL and trying to access it from the EXE. You can't do that; try using GetProcessHeap/HeapAlloc/HeapFree instead. – cf- Mar 31 '14 at 09:31
  • Visual Studio usually is quite forgiving when you mis-cast, but you really should not cast a pointer before printing it. Also, Visual Studio comes with a debugger. Why are you relying on `std::cout` ? – MSalters Mar 31 '14 at 09:31
  • 1
    @computerfreaker: That restriction was lifted with Windows 95 and Windows NT 3.1, , about 2 decades ago. – MSalters Mar 31 '14 at 09:32
  • @MSalters Are you sure? I've had to deal with exactly that issue (admittedly, I dealt with it pre-emptively; I've not actually faced it) in a recent DLL. I was allocating memory within the DLL and passing the resulting class object back to the EXE, and my research indicated the DLL and the EXE used different heaps so I would need to use the `Heap*` APIs to get around that. – cf- Mar 31 '14 at 09:34
  • The object is constructed in the .exe, just that the class is code FROM the dll. But it is created in my .exe. – Germán Diago Mar 31 '14 at 09:35
  • @computerfreaker: You might be confused by allocating memory in the DLL and **deleting** it in the EXE. That was a problem which was solved only a decade ago (VS2005, possibly earlier), not two decades. – MSalters Mar 31 '14 at 09:37
  • So this was my fault: the address can be printed and is identical at both sides. The dll wasn't being copied back after compilation. This might be a bug in my cmake file. But the crash is still there. I will update facts in the question. – Germán Diago Mar 31 '14 at 09:50
  • @MSalters I went back and looked again. [This isn't quite from a decade ago](http://stackoverflow.com/questions/4649739/when-exactly-would-a-dll-use-a-different-heap-than-the-executable), but it does seem to be exclusive to a statically-linked lib. [My original research](http://stackoverflow.com/a/3565808/2245528) wasn't as clear about what precisely the heap issue was; I just understood it to mean "don't allocate memory in one module and access it in another." – cf- Mar 31 '14 at 09:52
  • @computerfreaker: The first link (two libraries linked in, two heaps) indeed has an allocation problem, but that's because it ignores the solution introduced a decade ago: use the CRT in a DLL when you use DLLs. Using a statically linked CRT may avoid the need for DLLs altogether, but that's not the case here. – MSalters Mar 31 '14 at 09:58
  • Are you using the same runtime type build on both the exe and the dll? Is it possible that one has static runtime linkage and the other dynamic (you mentioned having to use NODEFAULTLIB)? If so, and for example, you have a static RT linked dll, but your exe is dynamic, and you delete the object allocated in the dll, within the exe, then you may be freeing memory that belongs to a different heap than the one the low-level free() is called on. – DNT Mar 31 '14 at 10:04

0 Answers0