Question

This is driving me nuts. I am using some 3rd-party code in a Windows .lib that, in debug mode, is causing an error similar to the following:

Run-Time Check Failure #2 - Stack around the variable 'foo' was corrupted. 

The error is thrown when either the object goes out of scope or is deleted. Simply allocating one of these objects and then deleting it will throw the error. I therefore think the problem is either in one of the many constructors/destructors but despite stepping through every line of code I cannot find the problem.

However, this only happens when creating one of these objects in a static library. If I create one in my EXE application, the error does not appear. The 3rd-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 is this weridness that is driving me mad. The EXE and 2 libs all use the same CRT library. There are no errors linking. The 3rd-party code uses inheritance and there are 5 base classes. I’ve commented out as much code as I can whilst still getting it to build and I just can’t see what’s up.

So if anyone knows why code in a .lib would act differently to the same code in a .exe, I would love to hear it. Ditto any tips for tracking down memory overwrites! I am using Visual Studio 2008.

Answer 1

OK, I tracked the problem down and it’s a cracker, if anyone’s interested. Basically, my .LIB, which exhibited the problem. had defined _WIN32_WINNT as 0x0501 (Windows 2000 and greater), but my EXE and the 3rd-party LIB had it defined as 0x0600 (Vista). Now, one of the headers included by the 3rd-party lib is sspi.h which defines a structure called SecurityFunctionTable which 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 cut a long story short, this meant a mismatch in object sizes between the LIBs and this was causing the Run-Time Check Failure.

Class!