The Developer's Guide to Debugging

The Developer’s Guide to Debugging Thorsten Grotker¨ · Ulrich Holtmann Holger Keding · Markus Wloka The Developer’s Guide to Debugging 123 Thorsten Grötker Ulrich Holtmann Holger Keding Markus Wloka Internet: http://www.debugging-guide.com Email: [email protected] ISBN: 978-1-4020-5539-3 e-ISBN: 978-1-4020-5540-9 Library of Congress Control Number: 2008929566 c 2008 Springer Science+Business Media B.V. No part of this work may be reproduced, stored in a retrieval system, or transmitted in any form or by any means, electronic, mechanical, photocopying, microfilming, recording or otherwise, without written permission from the Publisher, with the exception of any material supplied specifically for the purpose of being entered and executed on a computer system, for exclusive use by the purchaser of the work. Printed on acid-free paper 987654321 springer.com Foreword Of all activities in software development, debugging is probably the one that is hated most. It is guilt-ridden because a technical failure suggests personal failure; because it points the finger at us showing us that we have been wrong. It is time-consuming because we have to rethink every single assumption, every single step from requirements to implementation. Its worst feature though may be that it is unpredictable: You never know how much time it will take you to fix a bug - and whether you’ll be able to fix it at all. Ask a developer for the worst moments in life, and many of them will be related to debugging. It may be 11pm, you’re still working on it, you are just stepping through the program, and that’s when your spouse calls you and asks you when you’ll finally, finally get home, and you try to end the call as soon as possible as you’re losing grip on the carefully memorized observations and deductions. In such moments, you may eventually be choosing between restarting your debugging task or restarting your relationship. My personal estimate is that debugging is the number one cause for programmer’s divorces. And yet, debugging can be a joy, as much thrill as solving puzzles, riddles, or murder mysteries – if you proceed in a systematic way and if you are equipped with the right tools for the job. This is where The Developer’s Guide to Debugging comes into play. Thorsten Grotker,¨ Ulrich Holtmann, Holger Keding, and Markus Wloka speak directly to the entrenched developer, give straight-forward advice on solving debugging problems and come up with solutions real fast. Whether it is solving memory problems, debugging parallel programs, or dealing with problems induced by your very tool chain - this book offers first aid that is tried and proven. I would have loved to have such a book at the beginning of my debugging career – I would have gazed at it in amazement of what these debugging tools can do for me, and by following its advice, I could have saved countless hours of manual debugging – time I could have spent on other activities. For instance, I could have made my code more reliable such that in the end, I would not have had to do any debugging at all. v vi Foreword This, of course, is the long-term goal of professional programming: To come up with code that is right from the start, where all errors are prevented (or at least detected) by some verification or validation method. Today already, assertions and unit tests help a lot in increasing confidence into our programs. In the future, we may even have full-fledged verification of industrial-size systems. We’re not there yet; it may take years to get there; and even if we get there, whatever method we come up with certainly will not be applicable to programming languages as we know them. When dealing with today’s programs, especially those written in C and C++, we’ll still spend some time on debugging – and that’s where The Developer’s Guide to Debugging provides truly priceless advice. Saarland University, Spring 2008 Andreas Zeller Preface At the time of writing this book, we – the authors – are all working for a technology company that produces software, and more. Not on the same project or product, though. Yet we have all been called to support customers and colleagues when it came to debugging C and C++ programs – as part of our software engineering work, because we produce tools that let users write optimized simulation programs, or simply because we happen to develop debugging tools. And we kept repeating the same fundamental techniques, time and again, as there was no good textbook on debugging we could refer to. Until now. The Book’s 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, research papers, conferences, tutorials, and web links. The examples used in this book, and further material, can be downloaded from this website. vii Acknowledgments This book would not have come to exist without the help of numerous people. To begin with, we owe Mark de Jongh from Springer for encouraging us to write this book, for his support, and for his endless patience, which we stress-tested so many times. We are also grateful to a large number of people, among them our colleagues at Synopsys, for coming up with a steady stream of challenges in the area of software debugging, and for teaching us tricks how to crack tough nuts. This has been the seedbed for this book. Any attempt at presenting a complete list of names here is bound to fail. We would like to mention Andrea Kroll, as she was the first person asking us to write down a structured approach to debugging a simulation program, and Roland Verreet, for his encouragement and insights on marketing. We also thank Joachim Kunkel and Debashis Chowdhury for their support. Software has bugs, and so have books, especially early drafts. The help of brave people led to considerable improvements of this book’s quality and readability. We would like to thank, in alphabetical order, the following people for their contribu- tions to this process: Ralf Beckers, Joe Buck, Ric Hilderink, Gernot Koch, Rainer Leupers, Olaf Scheufen, Matthias Wloka, and Christian Zunker. We are grateful to Scott Meyers for his input on how to organize chapters and for his suggestions on how to present key material. We also want to express thanks to Andrea Holter¨ for her insightful comments written up during repeated front-to-back reviews. Mike Appleby, Simon North, and Ian Stephens deserve credit for helping us turn disjoint bursts of information into something – hopefully – much more intelligible, ix x Acknowledgments and also for covering up the many crimes against the English language we had committed. Any remaining errors and shortcomings are our own. Finally, it must be mentioned that this book would not have been possible without the enduring support from our families. Thank you! About the Authors Thorsten Grotker¨ was born in 1965 in Monchengladbach,¨ Germany. He received a diploma and doctorate degree in Electrical Engineering from Aachen University of Technology. Thorsten joined Synopsys in 1997, working in various functions in the areas of system level design and hardware verification. He is also an active member of the Open SystemC Initiative. Thorsten enjoys travel and photography. Ulli Holtmann was born in 1964 in Hildesheim, Germany. He studied Computer Science at the Technical University of Braunschweig and received his doctorate in 1995. He joined Synopsys in 1995 as an R&D engineer. From 1995–2000, he worked at the U.S. headquarters in Mountain View, and since then in Herzogenrath, Germany. He is married and has two children. Holger Keding was born in 1970 in Kempen, Germany. He studied Electrical Engi- neering and Information Technology at Aachen University of Technology, where he received his doctorate in 2002. He joined Synopsys in 2001 as Corporate Application Engineer, focusing on system level design and simulation methodol- ogy. He is an active member of the Open SystemC Initiative (OSCI). In his spare time he enjoys sailing, music, skiing, and spending time with his family and friends. Holger is married and has two children. Markus Wloka was born in Heidelberg in 1962, and grew up in Kiel, Germany. He received his Ph.D. in Computer Science from Brown University, USA, in 1991. From 1991–1996 he worked for Motorola SPS (now Freescale) in Tempe, USA, on projects that applied parallel processing to low power optimization of ASIC chips. In 1996 he joined Synopsys in Germany, where he currently holds the position of Director R&D. He is married to Anke Brenner, and has 3 children: Sarah, Thomas, and Kristin. His hobbies include reading, sailing, traveling, and buying the latest- and-greatest technological gadgets. Aachen, Thorsten Grotker¨ April 2008 Ulrich Holtmann Holger Keding Markus Wloka xi Contents 1 You Write Software; You have Bugs .............................. 1 2 A Systematic Approach to Debugging ............................ 5 2.1 Why Follow a Structured Process? . 5 2.2 Making the Most of Your Opportunities . 5 2.3 13 Golden Rules . 7 2.3.1 Understand the Requirements . 8 2.3.2 Make it Fail . 8 2.3.3 Simplify the Test Case . 9 2.3.4 Read the Right Error Message . 9 2.3.5 Check the Plug . 9 2.3.6 Separate Facts from Interpretation . 10 2.3.7 Divide and Conquer . 10 2.3.8 Match the Tool to the Bug . 12 2.3.9 One Change at a Time .

Load more