lAfter quite a long gap I got a break from enhancing my PowerPoint skills and got chance to do some hands on debugging. 3 instances which given the time I spend on PowerPoint, were heaven sent…
The first bug we were tracking down was a fairly tricky one since we didn’t have the hardware to test our code. So, two of us who were looking at this had no option but to just peer at the code. Everything seemed absolutely fine, the previous developer needed the contents of a widely used structure. But since this structure was in a different file had made an EXTERN out of it and then proceeded to use the contents. Initially we never even suspected this structure could be the problem. But after looking at all the other parts of the code and eliminating all the other scenarios we were left with nothing but to verify this variable. Nothing looked wrong at all; it was being filled upon initialization in a separate file and then being used. After lots more of staring and global searches we noticed that the structure being filled upon initialization was the local variable of the exact same name. The global had never been touched but since the names were the exact same and also that the variable was very widely used the developer had not verified that the wrong variable was being imported. So we just proceed to use the right one and things were fine.
The second one was a painfully slow debugging session that required about 3-4 hours. Here the software would start fine once, twice and but during the third time would get screwed up. This was slow because after u ran it the 3rd time there was no option but to reboot the system. And since it had the Vista OS it would login to a normal user account first from where you had to logout and then login to the admin account and then start the debugging. The intern in our group was with me on this run. We did so many reboots that we lost count but each time we painfully small amounts of progress. To what we didn’t know and to where we didn’t know either. Finally we found that for some strange reason the processor affinity being set in the application was not carrying over to the driver. This is given, we had no doubt that it carries over from the user space to the kernel space. We couldn’t figure out why the affinity was not sticking for this particular application whereas another application using the same driver was working just fine. We gave up on the reason behind because time was short and made a simple fix of re-asserting the processor affinity in the kernel one more time and things began working.
The third was a minor one where it took me 2 minutes to solve a problem that someone had spent an hour and a half looking into. It took me 2 minutes because I knew this problem existed and had faced it before :D. What happens with this tool is that it quietly installs a driver in the system32/drivers directory and never uninstalls it. So when you have a new driver your changes never show up since the driver already exists in the drivers directory and the OS picks it up every time from there (because the registry entry points to there also). So you have to remove the registry entry and additionally go delete this file only then will the new driver get loaded. Stupid thing, will need to be cleaned up by the next release :P
The first bug we were tracking down was a fairly tricky one since we didn’t have the hardware to test our code. So, two of us who were looking at this had no option but to just peer at the code. Everything seemed absolutely fine, the previous developer needed the contents of a widely used structure. But since this structure was in a different file had made an EXTERN out of it and then proceeded to use the contents. Initially we never even suspected this structure could be the problem. But after looking at all the other parts of the code and eliminating all the other scenarios we were left with nothing but to verify this variable. Nothing looked wrong at all; it was being filled upon initialization in a separate file and then being used. After lots more of staring and global searches we noticed that the structure being filled upon initialization was the local variable of the exact same name. The global had never been touched but since the names were the exact same and also that the variable was very widely used the developer had not verified that the wrong variable was being imported. So we just proceed to use the right one and things were fine.
The second one was a painfully slow debugging session that required about 3-4 hours. Here the software would start fine once, twice and but during the third time would get screwed up. This was slow because after u ran it the 3rd time there was no option but to reboot the system. And since it had the Vista OS it would login to a normal user account first from where you had to logout and then login to the admin account and then start the debugging. The intern in our group was with me on this run. We did so many reboots that we lost count but each time we painfully small amounts of progress. To what we didn’t know and to where we didn’t know either. Finally we found that for some strange reason the processor affinity being set in the application was not carrying over to the driver. This is given, we had no doubt that it carries over from the user space to the kernel space. We couldn’t figure out why the affinity was not sticking for this particular application whereas another application using the same driver was working just fine. We gave up on the reason behind because time was short and made a simple fix of re-asserting the processor affinity in the kernel one more time and things began working.
The third was a minor one where it took me 2 minutes to solve a problem that someone had spent an hour and a half looking into. It took me 2 minutes because I knew this problem existed and had faced it before :D. What happens with this tool is that it quietly installs a driver in the system32/drivers directory and never uninstalls it. So when you have a new driver your changes never show up since the driver already exists in the drivers directory and the OS picks it up every time from there (because the registry entry points to there also). So you have to remove the registry entry and additionally go delete this file only then will the new driver get loaded. Stupid thing, will need to be cleaned up by the next release :P
No comments:
Post a Comment