Troubleshoot potential memory overwrite issues. Windows weirdness
It drives me crazy. I am using some third party code in Windows.lib which, in debug mode, throws an error similar to the following:
Run-Time Check Failure #2 - Stack around the variable 'foo' was corrupted.
An error is thrown when either the object goes out of scope or is removed. Simply highlighting one of these objects and then deleting it will throw an error. So I think the problem is either one of the many constructors / destructors, but despite going through every line of code, I can't seem to find the problem.
However, this only happens when one of these objects is created in a static library. If I create it in my EXE application, no error appears. The third party code itself lives in a static lib. For example, this fails:
**3RDPARTY.LIB**
class Foo : public Base
{
...
};
**MY.LIB**
void Test()
{
Foo* foo = new Foo;
delete foo; // CRASH!
}
**MY.EXE**
void Func()
{
Test();
}
But this will work:
**3RDPARTY.LIB**
class Foo : public Base
{
...
};
**MY.EXE**
void Func()
{
Foo* foo = new Foo;
delete foo; // NO ERROR
}
So cutting out the "middle" .lib file makes the problem go away, and it's this insecurity that drives me crazy. EXE and 2 libraries use the same CRT library. No error links. Third party code uses inheritance and there are 5 base classes. I have commented out as much code as I can while still putting it together and I just don't understand what.
So, if anyone knows why the code in the .lib would act differently with the same code in the .exe, I'd love to hear it. Likewise, all memory tracking tips are overwritten! I am using Visual Studio 2008.
source to share
Ok I tracked down the problem and this is a cracker in case anyone is interested. Basically my .LIB that showed this issue. identified _WIN32_WINNT
as 0x0501
(Windows 2000 and up) but my EXE and 3rd party LIB identified it as 0x0600
(Vista). Now one of the headers included by the third party lib is this sspi.h
, which defines a named structure SecurityFunctionTable
that includes the following snippet:
#if OSVER(NTDDI_VERSION) > NTDDI_WIN2K
// Fields below this are available in OSes after w2k
SET_CONTEXT_ATTRIBUTES_FN_W SetContextAttributesW;
#endif // greater thean 2K
Th shortened the long history, it meant there was a mismatch in object sizes between LIBs and this was causing a runtime check error.
Class!
source to share
One possibility is that this is a mismatch calling convention - make sure your libraries and executables are configured to use the same default calling convention (usually __cdecl). To set this open your project properties and go to Configuration Properties> C / C ++> Advanced and look at the Calling Convention option . If you call a function with the wrong calling convention, you will completely mess up the stack.
source to share
Is your .lib file related to the .lib library? I assume from your example that you include a header with a destructor declaration; without it, an exception of this type is allowed, but can lead to UB (in a bizarre way, contrary to the general rule that something must be defined before use). If the .lib files are not linked together, it is possible that the user operator delete
or destructor has some weird linking issues, and while it shouldn't, you can never tell if it won't.
source to share
Without seeing more code, it's hard to give you a solid answer. However, to track memory overwrites, I recommend using WinDbg (free from Microsoft, search for Debugging Tools for Windows).
Once you've connected to a process, you can set breakpoints for it to access memory (read, write, or execute). He's really powerful, but he should especially help you with this.
source to share