Finding bugs always seems to be much harder than fixing them.I wanted them to understand what I was trying to do and vice versa.
Ill first try to be able to reliably replicate the problem (especially on my local machine). Methods Of Testing And Debugging Hardware And Software Plc Series Of EliminationThen through a series of elimination (and this is where I think its problem dependent) try to identify the problem. Methods Of Testing And Debugging Hardware And Software Plc Software While ChallengingIf not, I start to mechanically trace the data back through the software while challenging basic assumptions made by the software. This is where having a dump (or better, a live, broken process) can be truly invaluable. The number of times Ive found a bug in that component that I or a colleague would swear is working fine is massive. The subtitle is The 9 Indispensable Rules for Finding Even the Most Elusive Software and Hardware Problems. His list of debugging rules available in a poster form at the web site (and theres a link for the book, too) is. Make a copy of the section of problem code, and start removing features from it, one at a time. Through this process your will either remove the feature with the bug (and hence, locate the bug), or you will have isolated the bug down to a core piece of code that contains the essence of the problem. And once you figure out the essence of the problem, its a lot easier to fix. If it proves to be wrong, I start off with a different hypothesis. I work on Windows applications and have found windbg to be extremely helpful in finding bugs. When the newbies try to do it it seems more like random shooting and hoping to hit one. I guess mainly because they lack the experience to start with the most plausible hypothesis. ![]() ![]() A variation on this is to get the code to a point where it is working, with less functionality, than not working with more functionality. Id rather make 50 runs to gather information about the bug rather take a wild swing and hope it works. Check return values, liberally use assert, use some kind of reliable logging mechanism and log everything. ![]() It may not seem like youre finding the bug, and you may not be. The logging might help you find another bug though, and eventually once youve gone through enough code, youll find it.faster than setting up debuggers and trying to reproduce the problem, single stepping, etc. Ive come up with a fairly arbitrary classification system, but it works for me: all bugs fall into one of four categories. Keep in mind here that Im talking about runtime problems, not compiler or linker errors.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |