Question

I understand that this is a very broad question, but I was very curious about this so I decided to ask. Please understand that what information I give is unfortunately all that I have 🙂

---

I was wondering, in a C++ program, what possible situations could the following case happen in:

The following is the (mimicked) code snippet. It uses a class whose implementation and member function implementation is hidden in a DLL:

namespaceFromSomeDll::userDefinedClass myObject = new namespaceFromSomeDll::userDefinedClass();
myObject->someMemberFunction();
delete myObject;

The situation:

This code snippet as is will throw an exception on the third line saying “Cannot access memory location” or something along these lines. There is no mention of not being able to access “protected memory”, (ie: not like a buffer overflow), just cannot access memory.

Now, if the second line is commented out:

namespaceFromSomeDll::userDefinedClass myObject = new namespaceFromSomeDll::userDefinedClass();
// myObject->someMemberFunction();
delete myObject;

…there is no exception and the code runs to the end and the delete call executes normally.

I was wondering what the member function call could possibly be doing to cause this problem? What kind of action could it perform that would “lock” the memory, or maybe even change the object location or deallocate the pointer or something? (Can that even happen?)

---

This question was actually asked of me by someone else who slightly looks up my slightly-higher programming skill, and I was totally unable to answer. They were working with a third party library and trying to troubleshoot something that yet another person had written. Convoluted, I know, and thus the lack of any further information.

Answer 1

The problem with declaring and implementing a class in a DLL and simply using it from outside is that “outside” needs to know the layout of your class. At a minimum the calls to new/ delete operators must know how much memory must be allocated and freed.

Based on what you said, my best guess is that the client is using header file, which declares namespaceFromSomeDll::userDefinedClass, that doesn’t match the header file that was used to build the actual DLL (i.e. someone added or removed a member variable in a DLL and rebuilt it after the client code was already built). Because of that, when you call someMemberFunction(), it access memory which is outside of the allocation bounds and you end up with a heap corruption.

This is what’s causing the crash. Otherwise, there’s no concept of “locked” memory in a sense that I think you are thinking of.

This is a very common issue with having multiple binary modules interact with each other. For this reason COM (and other custom implementations) use class factory methods which perform the actual object allocations within the DLL code and also instead of destroying the object yourself, DLL would implement a method which would clean up the object on your behalf (in COM, this is done through reference counting, so the object deletes itself whenever it is no longer used by anyone).