How could a call to a member function of a class cause that object to no be longer "delete-able"?

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.

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).

Not knowing the code in the class's destructor, then yes, it's definitely possible. Consider a member function that deletes a member, then the destructor tries to delete it again. Bad things will happen. Including possibly demons flying out of your nose.

Example:

class MyClass {
  public:
    void someMemberFunction() {
        // random code
        // done with foo, clean it up
        delete this->foo;
    }
    ~MyClass() {
        delete this->foo;
    }
  private:
    Foo foo;
};

Another possibility is some type of memory corruption in someMemberFunction that doesn't cause effects until the destruction of the object.

class MyClass {
  public:
    void someMemberFunction() {
        this->foo = new int[20];
        this->foo[30] = 123;
    }
    ~MyClass() {
        delete this->foo;
    }
  private:
    int *foo;
};

There are many possibilities. Here are some of them:

• That method detete something that will be deleted again in the destructor.
• That method is causing a heap corruption.
• The method is deleting the object, by calling "delete this" (yes, C++ allow that too).

Supplemental answer:

Another case where you can make an object non-deletable: Say myObject has a pointer member (that it allocated) and you can access that pointer. If you delete the pointer, bad things will happen if you try to delete myObject. This is generally a breach of your contract with the object, so don't do it.

In regards to "locking": On Windows, at least, it is possible to lock (protect) memory, but it's rare to do this manually (let Windows worry about memory protection). You can protect memory with VirtualProtect. The only time I've ever seen it used was in a custom memory debugger and that debugger does some pretty unspeakable things (starts with "r" and ends with "untime code modification").

Also, for debugging purposes, keep an eye on the "invalid" address (assuming the system tells you what it is) and the memory it points to. The C++ Runtime has couple of constants with special meanings that can be very useful to know. Table 1 of this page from MSDN has a list of the constants.

I believe it is also possible for an object to manually free and possibly move itself in a member function, but I don't see a situation where that would be remotely sane. What does happen is resizing/ moving/ freeing pointer members, but that shouldn't be a problem here.