Logs + Scripts = Ownage

At times, I like to keep scores between Development and Customer Support (CS). If a problem is on the customer’s side, a point is awarded to development and if the problem is with our code, a point is awarded to customer support. Then there are the many special cases, for example problems with documentation (points for CS), problems with API design (more points for CS), problems fixed for another customer already (points for Development) problems which are already fixed in later versions (points for Development) and problems with API misuse (more points for Development). Extra points are received for quick responses and this is where good logs and handy scripts are put to good use.Good logs are essential. You must be able to debug your code and you must be able to do so remotely. People who are not used to writing programs that are used inside other programs may sometimes depend on error codes or user descriptions to discover what went wrong. However when you are developing a library, you must have good logs. For example, things could have started going wrong long before the actual error or exception. Most of the time, you have to go to the beginning of the session to track an object from its creation, look through its state changes, and then find out what event in it’s past caused the error. At times, you need to track the stack conditions from initialization to find out what went wrong.

Such cases are due to the occasional resource leak. This is where you need logs to tell you when an object was allocated and when it was deleted. If the object has access control, the logs also need to report when it is locked and unlocked. This adds up to a lot of information which is too much to cover manually. Here is where you need to master a scripting language. It’s not an absolute necessity; it’s just the quickest way to analyze logs. When you need to do text processing and regular expressions, scripts are the way to go. Here at RADVISION we use TCL scripts, although Perl and Python are options that are more common.

The final step is to use C Macros to print the file and line of the calling function, like so:

ResourceId AddResourceDeb(
    ResourceParameters parameters,
    const char * filename,
    int lineno);

#if _DEBUG
#define AddResource(parameters) AddResourceDeb(parameters,__FILE__,__LINE__)
#endif

This means that the function will be able to print the exact location where it was called to the log. Your well-written scripts will be able to direct you to the exact location of the problem, that is, if the problem is indeed in your code. Sometimes the scripts direct you to a filename that is in the client’s application.

Here is where you quickly press the “reply” button and send the customer to D:\coolProject\videoApp\myFile.c, line 845, to check why he/she is not releasing the resource allocated there. Result: Ownage.