DLLs and corruption

   Yet another bug for memory corruption. A class and its members were available as a part of a dll and the our application was using this class for a necessary functionality.  It was working fine until one fine day, the member function started to fail.

   For some crazy reason, a bool member variable of the class in the dll was set to false causing the failure, but there wasn't any exposed function to reset the boolean variable to false. The constructor too had set the variable to true. It didn't make sense initially and was increasing pointing to memory corruption. But this was an application working from quite a long time. Thought of setting up a debugger, but what the heck? Static analysis should still help us :-)

  From the repository, we realized there was a new member variable added to the class and the re-build version of dll was released. However, all other projects like our application which were using the header file wasn't rebuild. Now this is a problem. To confirm if this was the root cause, we went back to the allocation of the instance and found that this was in the stack and as the size of the class is calculated during compilation, and as our project (using the header file) wasn't re-compiled, excess memory was used by the object in the stack. This excess memory was supposed to be used by subsequent objects in the stack and which happened to reset memory (the boolean variable back to false).

   Now, that's a dll hell ;-)