groetker - the developer's guide to debugging (springer, 2008)

[...]... so on There is almost no end to this list of environmentrelated questions In the end debugging boils down to trial-and-error Try to understand the likelihood of certain changes causing the failure and the cost of undoing them for testing purposes 2.3.7.2 Separate Changes of the Environment vs Source Code Changes There is a practical way to find out if one of the source code changes is related to the bug... what is causing the problem Running a memory debugger (see Chapter 4) and normal source code debugging (see Chapter 3) may not solve 12 2 A Systematic Approach to Debugging the puzzle for you You may have to bite the bullet and face the tedious task of sideby-side debugging comparing data, log files and the flow of control in both versions, concurrently, side-by-side 2.3.8 Match the Tool to the Bug Leave... In the course of our software development work we have often been called upon to support customers and coach colleagues on how to find bugs They were aware of the topics they had been taught in school: object-orientation, code reviews, and black-box vs white-box testing, but most had only superficial knowledge of debugging tools, and rather fuzzy ideas about when to use a particular approach and what to. .. B.3.2), and store a checkpoint before each change to the OS, tools, and installed software You can then easily return to previous states of your machine If, however, the old source code revision works but the current breaks, then a difference in the source code base is the likely cause If source code changes are the problem, then you can try to narrow down the search space and isolate the problematic... and how to debug them Changes to the 2.3 13 Golden Rules 11 source-code base are one, but not the only possible reason for a bug that suddenly appears Was the compiler modified? Were third-party libraries changed? Perhaps the program invokes other programs outside of the source-code control system and one of them changed? When the feature worked last Wednesday, was it run on the same host as today? Were... conversion is not feasible OK, so how to best read this book? Well, it depends You can read the book cover -to- cover, which isn’t a bad approach if you want to learn debugging from the ground up Chapter 2 (A Systematic Approach to Debugging) presents an overview of various opportunities to gather information and analyze problems Then in Chapter 3 (Getting to the Root – Source Code Debuggers) you’ll... infor- 2.3 13 Golden Rules 9 mation may be missing although the witnesses have the best intentions and are convinced that they describe the complete and unabridged truth 2.3.3 Simplify the Test Case The next step is to simplify the test case You do this in order to • rule out factors that do not play a role, • reduce the runtime of the test case and, most importantly, • make the test case easier to debug... debug output to my customer.” • “After I linked my test code into the executable I could not spot the bug anymore I didn’t even call one of the routines It’s a mystery.” You need to understand the Heisenbug traits in order to successfully hunt this elusive creature Typically, it is either a race-ist, a memory outlaw, or an idealist 2.5.3.1 The Race-ist So-called race conditions are often the reason for... details Analyze the error description and log files and form a theory what might have gone wrong Then build a test case that results in an error matching the customer’s description and log files The next steps are obvious: debug the failure, fix it, ship a new release to the customer, and cross your fingers that the problem is gone 2.5.5.2 On-site Debugging A different approach is to debug on-site Compile... debug them • Separate changes of the environment and source code changes – Track down changes of the environment – Isolate source code changes via back-out builds • Zoom in and conquer – Memory debugger – Conventional source code debugging – Side-by-side debugging 2.3.7.1 Assemble a List of Potential Problems and How to Debug Them Obviously, the first step is to understand how to slice and dice the problem . Keding Ulrich Holtmann Markus Wloka Internet: http://www .debugging -guide. com Email: authors @debugging -guide. com ISBN: 97 8-1 -4 02 0-5 53 9-3 e-ISBN: 97 8-1 -4 02 0-5 54 0-9 Library of Congress Control Number: 2008929566 c  2008. Website We have created the website http://www .debugging -guide. com to aug- ment the book, by listing up -to- date references on the topic of software debugging: access to tools, books, journals,. with the right tools for the job. This is where The Developer’s Guide to Debugging comes into play. Thorsten Gr ¨ otker, Ulrich Holtmann, Holger Keding, and Markus Wloka speak directly to the