Messages from Log.wtf() sound pretty bad

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

      Recently, i happened to come across this section of code causing a fault    sampleClass object; std::vector ::iterator it; for(it=object.someFunction().begin();it object.someFunction().end();it++) {          // code to de-reference the iterator (it->) }       At first look, it looked fine and there didn't seem to be any problem. someFunction() returns a vector of type otherClass and the de-reference was causing a fault. Upon closer look, we found that someFunction() was returning the vector by value (a very bad design) and new temporary objects were created in the for loop control expressions. This temporary objects lifetime ends at the end of the control expression (as soon as .begin() or .end() is executed) and iterator (it) became a dangling reference and subsequent access in the body of the loop caused the fault. Enjoyed figuring this one out :-)