Messages from Log.wtf() sound pretty bad

In some projects in C, it becomes necessary to share and access global variables across file(s). In such cases, developers tend to declare the variable as global in a master source file and declare it as extern in other files. This works fine, but it is a good practice to keep all declarations in a header file. But if we keep it the declaration in a header file and include the header file in more than one file, [code] common.h int gvalue; it would result in a linker error saying gvalue has been redefined. The work around is to use the #define macro in the header file, [code] common.h #if OWNER 1 #define EXTERN #else #define EXTERN extern #endif EXTERN int gvalue; source1.c #define OWNER 1 #include "common.h" // gvalue is a global variable defined in source1.c ... source2.c #include "common.h" // gvalue is a global variable decalred as extern in source2.c ...

Breakages are seen quite often in a large project with many developers, especially when there is a dependency between various components in the project. A change in one component could have a negative impact on other dependent ones. It gets the developer/sustainer baffled, specially when some of his/her genuine changes are released and are available in latest labels, and consequently there is a immediate urge to find out the root cause as soon as possible. A direct approach to setup a debugger like ddd/gdb on the label having the breakage can help identify the bug and solve the same. However, it requires some time to setup and to debug, especially in embedded systems. Hence, other debugging approaches can save a lot of time in such cases. * Most systems have a well defined logging functions in place. Functions have an entry and exit logs. Logs could be taken from both working and non-working builds and they could be compared to get a rough idea as to where the code flow is devi...

Memory leak is a challenge that awaits any developer working in c. There are many tools, which perform both static and dynamic (run-time) analysis of the source code. These tools report memory leaks, if any. Klocwork is one such tool that can do. However, these are tools which require license fees. There are quite a few open-source projects which basically wraps all calls to malloc and free to custom functions. These functions monitor the usage of memory and finally call the actual memory allocation/deallocation routines. [Code] #include int main() { int *ptr = (int*)malloc(sizeof(int)*32); return(0); } Few tools have a macro, #define malloc custom_malloc #define free custom_free It is this custom_malloc, which gets invoked, void* custom_malloc(size_t size) { // Update report with the requested size return(malloc(size)); } And once the program is executed, the developer gets a chance to have a look at the report (stored in a file) along with other details like line number ...

There is always a perception that a working code is considered very stable and free of bugs. Quite a few decisions like estimation for a new feature, estimation for resources to support that code are taken merely based on that very illusion. I happened to work on one issue, which proves otherwise, encoding_library(void *ptr, unsigned int length) { // Parameter check // ptr points to a chunk of memory supposed to have encoded data // Invoke a function to perform a part of the encoding encode_partial(ptr, &length); // Invoke another function to continue encoding on the same buffer encode_complete(ptr, &length); } encode_partial(void *ptr, unsigned int* length) { // This function fills the buffer with the encoded data and as and when the memory of buffer is finished, it passes the memory to the caller and requests for a new chunk of memory. This happens until the encoding corresponding to this function is finished... } encode_complete(void *ptr...

I was working on a feature (to be developed in c++), which wasn't yet committed to any products :-( but had a high probability to get approved. Accordingly, i was expected to work in the test environment with temporary resources like conditional compilation and other resources specific to the platform. Naturally, there is a tendency to develop the code and have a temporary hack like #define NEW_FEATURE_NUMBER TRUE The code was finished, the testing was done, everything is cool. We are just waiting for the approval from management :-). However, the temporary hacks are still present in the code and as the work was completed, i was asked to move on to other projects. From here on, as and when the feature is approved, i would be expected to complete the formalities and have the changes in the main release line. Here comes the problem, there is a high probability that i might forget to remove the temporary hacks and have the code released with these hacks, and might have to t...

I was going through news articles this morning, just like any other day, and landed up with some errors on http://economictimes.indiatimes.com Internal Server Error 500 Exception: EAccessViolation Message: Access violation at address 01BA25CC in module 'cms.dll'. Write of address 01C13804 =================================================================== Microsoft OLE DB Provider for SQL Server error '80040e57' String or binary data would be truncated. /OCT/hit_counter.asp , line 27 ==================================================================================== Good enough to conclude on what database they are working on ;-) Wish i could get the version info, to search for some vulnerability...

I started out debugging various issues all these years , ending up with head aches on a few occasions, enjoying success almost all the time. I feel it is very critical to get the following things sorted out before debugging on any issue, * Quickly get set into a pattern of reproducing the issue. [It is frustrating, when the pattern becomes very complex like in multi-threaded applications] Testers often claim reproducibility to be 50% or anything less than 100%, but i have always found it to be 100% once the pattern is found. * Next, take the bug purely on its technical merit, ignore the business impact and managers pushing for a quick fix ;-) * Believe in the cracking it out, after all, its just yet another bug * Now that half the battle is done, use the best debugging tool available in hand. Through out the years, i have started enjoying debugging and eagerly wait for new ones with the hope that developers always introduce defects :-)