Messages from Log.wtf() sound pretty bad

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

We once had to develop a feature to basically undo an existing feature, developed in-house, and use a third party code instead. As in any project, the motivation for the same happened to be financial benefits and other reasons beyond technical understanding. The in-house code was designed to read data from a file (part by part), having encoded information, and to decode the information. It would have been great had the third party application too had been designed similarly. Unfortunately, it was designed to read data only from a buffer and it wouldn't accept any file pointer. So it was evident that someone had to feed this third party code with a pointer to the buffer and moreover it doesn't seem to be a big deal to load the data from the file and store it in a buffer. But here comes our problem, we are in embedded systems and we didn't have the luxury to have a huge buffer in the RAM. But the good news was that the real time operating system was supporting virtual me...