Why is vector deleting destructor being called as a result of a scalar delete?

Question

I have some code that is crashing in a large system. However, the code essentially boils down to the following pseudo-code. I\'ve removed much of the detail, as I have tried

Answer 1

In my case, it's that the wrong 'flavour' of deleting destructor appears to be being applied: i.e. vector rather than scalar.

That's not the problem here. As per the pseudocode in Mismatching scalar and vector new and delete, the scalar deleting destructor simply calls through to the vector deleting descructor with a flag saying "Do scalar destruction rather than vector destruction".

Your actual problem, as noted by other posters, is you're allocating on one heap, and deleting on another. The clearest solution is to give your classes overloads of operator new and operator delete, as I described in an answer to a similar question: Error deleting std::vector in a DLL using the PIMPL idiom

Answer 2

Microsoft provides the source for their C runtime; you can check there to see what _CrtIsValidHeapPointer does. On my installation, it's under C:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\crt\src\dbgheap.c.

One other suggestion is to check the disassembly of

delete newObj; // scalar delete

and compare it to the disassembly generated for

delete[] newObj;

and

delete pointerToClassLikeMyClassThatIsInExeAndNotDll;

to test your theory about delete[] being called. Similarly, you could check the call stack for

delete pointerToClassLikeMyClassThatIsInExeAndNotDll;

to test your theory about mydll_d.dll!operator delete() versus myexe_d.exe!operator delete().

Answer 3

This behavior is special to MSVC 9, where the delete operator for a exported class, that has a virtual destructor is implicitly generated and mangled to vector dtor with an associated flag, where 1 means (scalar) and 3 means (vector).

The true problem with this thing is, that it breaks the canonical form of new/delete, where the client coder is not able to disable the vector delete operator in its code, if he thinks, that it is a bad idea to use it.

Moreover the vector dtor, also seems to be executed wrong, if the new is allocated in another module than the module the implementation resides in and is then hold in a static variable via a reference count, which executes a delete this (here the vector dtor comes into play) on process shutdown.

This matches to the heap problem 'bshields' already mentioned before, the dtor is executed on the wrong heap and the code crahses either with 'cannot read that memory location' or 'access violation' on shutdown - such problems seem to be very common.

The only way around this bug, is to forbid the usage of a virtual destructor and execute it your own, by enforcing the usage of a delete_this function from the base class - stupid as it is you imitate the stuff the virtual dtor should do for you. Then also the scalar dtor is executed and on shutdown any ref counted objects shared between modules, can be instantiated in a safe way, because heap is always addressed correctly to the origin module.

To check, if you have such problems, simply forbid the usage of the vector delete operator.

Answer 4

Thank you for all the answers and comments. All have been useful and relevant.

Any further information is still welcome.

---

The following was a comment on my question from Hans Passant:

Once you start exporting classes from DLLs, compiling with /MD becomes very important. Looks like /MT to me.

As a result of that, I took a closer look at the linkage setting throughout the project. I found a 'buried' instance of /MT and /MTd that should have been /MD and /MDd, plus some related inconsistencies in other settings.

Having corrected those, no assertion is now thrown, and the code appears to be behaving correctly.

---

Here are some of the things to check when experiencing crashes or assertion failures at execution leaves scopes and destructors are called. Ensure that throughout all projects (including dependencies) and in all configurations (especially in the problematic one):

(Here the *.vcproj paths are relative to </VisualStudioProject/Configurations/Configuration/>.)

• The correct runtime is selected in C/C++ | Code Generation | Runtime Library <Tool[@Name="VCCLCompilerTool"]/@RuntimeLibrary>;
• Appropriate definitions (if any) are made in C/C++ | Preprocessor | Preprocessor Definitions <Tool[@Name="VCCLCompilerTool"]/@PreprocessorDefinitions> especially relating to the use of static versus dynamic libraries (e.g. _STLP_USE_STATIC_LIB versus _STLP_USE_DYNAMIC_LIB for STLport);
• Appropriate versions of libraries are selected in Linker | Input | Additional Dependencies <Tool[@Name="VCLinkerTool"]/@AdditionalDependencies> especially relating to static runtime libraries versus 'wrappers' for DLLs (e.g. stlport_static.lib versus stlport.N.M.lib).

---

Interestingly, the scalar 'flavour' of delete I'd expect still does not appear to be being called (the breakpoint is never hit). That is, I still only see the vector deleting destructor. Therefore, that may have been a 'red herring'.

Perhaps this is just a Microsoft implementation issue, or perhaps there's still some other subtlety I've missed.

Answer 5

Sounds like this could be an issue of allocating off of one heap and trying to delete on another. This can be an issue when allocating objects from a dll as the dll has its own heap. From the code you're showing it doesn't seem like this would be the problem but maybe in the simplification something was lost? In the past I've see code like this use factory functions and virtual destroy methods on the objects to make sure that the allocation and deletion happens in the dll code.