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 ;-)

Interesting bug - Reminds handling of temp objects in c++

     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 :-)

Version control @ localhost - TortoiseCVS

Its been quite a while that i have used clearcase for source control and have started working in a new environment without clearcase. I was looking up to setup a configuration management to be setup locally in my machine to handle the code changes that i have been working on for some time. These changes were needed for adhoc need basis and didn't really make sense to be present in the main CVS server maintained in the organization.

I was searching for open source, easy-to-setup and easy-to-use configuration management tool and found TortoiseCVS (http://www.tortoisecvs.org). It is quite straight forward and allows to create a local repository and it hardly took 10 minutes to have it installed, although it took quite a while searching for the same :-).

A strict NO to strcpy

Its been quite a few times that i have seen code using strcpy() to copy data from a source string to destination. For some or the other reason, strncpy() isn't given a fair chance. Few developers don't want the extra effort of maintaining the length of the source string, and the other few trust their source strings and expect it to be null-terminated.

With strcpy() comes risk of stack/heap overflow when the source string isn't null terminated and this was the basis of many buffer overflow attacks. A better approach would be to use strncpy() provide the length of the source string. Yes, one has to calculate the length of the source string, possibly by using strlen().

So wouldn't strlen() too depend on the null character at the end of the source string? Isn't it too vulnerable to a string which isn't null terminated?

Yes it is, but then what is the worst case with strlen()? It is after all going to read chunks of memory and would never modify any of the memory contents unlike strcpy(), which modifies the destination string.

Security and Outsourcing

Really wonder how outsourcing has become a point of technical discussions :-)

Uninitalized variable

I have heard a lot about initializing variables and have wondered why so much is being said about it as long as the developer is going to use the variable sensibly, but i happened to work on a issue where a uninitialized variable (supposed to hold a proper enum value) was passed on to a function working on the following enum values,

-----------------------------------------------------------------------------------------------------------------
[Code]

enum property
{
NAME = 0,
TELEPHONE,
ADDRESS,
E-MAIL,
FAX,
PAGER
};

void act_on_property(int property_type)
{
switch(property_type)
{
case NAME : ...
case TELEPHONE : ...
case ADDRESS : ...
case E-MAIL : ...
case FAX : ...
case PAGER : ...
default : log ("invalid value");
}
}
-----------------------------------------------------------------------------------------------------------------


The problem was that the variable was a global one, having static storage class.

In one particular code flow, the global variable wasn't set to the proper enum value and was passed directly to this function and the default value of 0 ( uninitialized variables being zero filled ) was handled in the switch-case as a NAME property and this had its own negative impact on the use case and caused a considerable time to debug (sounds simple in this case though).

This experience just signifies the importance of initializing variables and in our case, we introduced a new enum value by the name of INVALID_PROPERTY and used this to initialize the global variable, making sure that any future problem could be caught in the default case of the switch-case with a graceful exit. This also gives a hint of having a value in every enumeration which signifies a invalid value.

exception handling

It is indeed worth the time spent in handling exceptions, an unhandled exception often exposes quite a lot of vital information, like the following one from a popular video downloading site, exposing the details of a database table,