What do you think?
Rate this book
Why Programs Fail: A Guide to Systematic Debugging
Why Programs A Guide to Systematic Debugging is proof that debugging has graduated from a black art to a systematic discipline. It demystifies one of the toughest aspects of software programming, showing clearly how to discover what caused software failures, and fix them with minimal muss and fuss. The fully updated second edition includes 100+ pages of new material, including new chapters on Verifying Code, Predicting Erors, and Preventing Errors. Cutting-edge tools such as FindBUGS and AGITAR are explained, techniques from integrated environments like Jazz.net are highlighted, and all-new demos with ESC/Java and Spec#, Eclipse and Mozilla are included. This complete and pragmatic overview of debugging is authored by Andreas Zeller, the talented researcher who developed the GNU Data Display Debugger(DDD), a tool that over 250,000 professionals use to visualize the data structures of programs while they are running. Unlike other books on debugging, Zeller's text is product agnostic, appropriate for all programming languages and skill levels. The book explains best practices ranging from systematically tracking error reports, to observing symptoms, reproducing errors, and correcting defects. It covers a wide range of tools and techniques from hands-on observation to fully automated diagnoses, and also explores the author's innovative techniques for isolating minimal input to reproduce an error and for tracking cause and effect through a program. It even includes instructions on how to create automated debugging tools. The text includes exercises and extensive references for further study, and a companion website with source code for all examples and additional debugging resources is available.
544 pages, Paperback
First published October 1, 2005
Ratings & Reviews
Friends & Following
Create a free account to discover what your friends think of this book!
Community Reviews
Displaying 1 - 6 of 6 reviews
July 15, 2017
Немного странная книга. Это учебник по курсу, который исследователь в области автоматизированной отладки читает своим студентам.
Автор рассказывает про bleeding edge в автоматизированной отладке на 2009 год. Но, судя по отладчикам, которыми сейчас приходится пользоваться, ничего особо не поменялось. В книге есть всякие интересные идеи и примеры:
* Автоматическая минимизация входных данных, которые приводят к багу. Или минимизация разницы между failing run и passing run (т.н. delta debugging). При этом в качестве входных данных могут рассматриваться совсем разные вещи:
- собственно входные данные (например, HTML-документ, который приводит к падению печати в FireFox)
- записанные действия пользователя (куда мышку двигал, на какие кнопки нажимал)
- расписание context switch в многопоточном приложении (так можно выделить, по сути, порядок выполнения каких-то частей, который приводит к ошибке)
* Нахождение всяких static и dynamic backward/forward slices. Это выделение частей программы, которые могут как-то влиять на данную строчку, либо наоборот, на которые может влиять данная строчка. Если есть возможность удобно выделять такие куски, то можно сильно сократить количество кода, на которое нужно смотреть, чтобы понять, что происходит в конкретной строке.
* Omniscient debugging. Возможность записывать полностью всё выполнение программы и потом во время отладки ходить не по текущему стеку вверх-вниз, а ходить по времени. Вот это должно быть очень-очень круто. Но в open-source отладчиках пока, похоже, нет ничего юзабельного (такая возможность в GDB вроде как замедляет выполнение в 50000 раз).
* Поиск аномалий при нескольких прогонах кода (например, строки, которые запускаются только в failing runs и никогда в passing runs и наоборот).
* Извлечение и сравнение "состояний" программы (memory-graphs) и выделение цепочек cause-effect из них.
* Выявление проблемных мест/компонент в коде (на основании багов/фиксов из трекера), чтобы этим местам можно было уделять особенное внимание при QA, например.
Со всеми этими крутыми штуками есть только одна проблема. Вообще непонятно, как это применять в реальной жизни. Вот прям взять какой-нибудь известный баг и применить к нему полученную информацию. Чтобы использовать приведённые подходы, подойдёт совсем не любой язык программирования. И нужно в эти подходы вкладываться с самого начала. И не факт, что они вообще на конкретном проекте заработают. Поэтому почитать про это любопытно, но практической ценности немного.
Книгу можно рекомендовать, если хочется почитать "как оно там бывает". Она немаленькая (388 страниц), местами сухая, поэтому иногда хочется, чтобы она уже поскорее закончилась.
Автор рассказывает про bleeding edge в автоматизированной отладке на 2009 год. Но, судя по отладчикам, которыми сейчас приходится пользоваться, ничего особо не поменялось. В книге есть всякие интересные идеи и примеры:
* Автоматическая минимизация входных данных, которые приводят к багу. Или минимизация разницы между failing run и passing run (т.н. delta debugging). При этом в качестве входных данных могут рассматриваться совсем разные вещи:
- собственно входные данные (например, HTML-документ, который приводит к падению печати в FireFox)
- записанные действия пользователя (куда мышку двигал, на какие кнопки нажимал)
- расписание context switch в многопоточном приложении (так можно выделить, по сути, порядок выполнения каких-то частей, который приводит к ошибке)
* Нахождение всяких static и dynamic backward/forward slices. Это выделение частей программы, которые могут как-то влиять на данную строчку, либо наоборот, на которые может влиять данная строчка. Если есть возможность удобно выделять такие куски, то можно сильно сократить количество кода, на которое нужно смотреть, чтобы понять, что происходит в конкретной строке.
* Omniscient debugging. Возможность записывать полностью всё выполнение программы и потом во время отладки ходить не по текущему стеку вверх-вниз, а ходить по времени. Вот это должно быть очень-очень круто. Но в open-source отладчиках пока, похоже, нет ничего юзабельного (такая возможность в GDB вроде как замедляет выполнение в 50000 раз).
* Поиск аномалий при нескольких прогонах кода (например, строки, которые запускаются только в failing runs и никогда в passing runs и наоборот).
* Извлечение и сравнение "состояний" программы (memory-graphs) и выделение цепочек cause-effect из них.
* Выявление проблемных мест/компонент в коде (на основании багов/фиксов из трекера), чтобы этим местам можно было уделять особенное внимание при QA, например.
Со всеми этими крутыми штуками есть только одна проблема. Вообще непонятно, как это применять в реальной жизни. Вот прям взять какой-нибудь известный баг и применить к нему полученную информацию. Чтобы использовать приведённые подходы, подойдёт совсем не любой язык программирования. И нужно в эти подходы вкладываться с самого начала. И не факт, что они вообще на конкретном проекте заработают. Поэтому почитать про это любопытно, но практической ценности немного.
Книгу можно рекомендовать, если хочется почитать "как оно там бывает". Она немаленькая (388 страниц), местами сухая, поэтому иногда хочется, чтобы она уже поскорее закончилась.
November 16, 2012
The book presents a lot of cutting-edge research studies on automated debugging techniques. I think this is the main strength of the book. It also has good chapters that formalize the general intuition of debugging and introduce the theory of these processes. The only reason, why I gave 4 stars and not 5 is that sometimes I was expecting more real-life guidelines for debugging and was tired (at some points) of cutting-edge automated prototype tools.
November 20, 2018
Amazing fell-researched and structured knowledge on debugging programs.
The most important topics for me from this book are scientific method and deduction and how to use those to find failure causes effectively.
Though slightly dated, the book is a gold nugget for all software engineers.
The most important topics for me from this book are scientific method and deduction and how to use those to find failure causes effectively.
Though slightly dated, the book is a gold nugget for all software engineers.
August 24, 2020
Best debugging book I've read so far.
Want to read
November 19, 2021[]
August 16, 2016
A good intro for beginners into defects and debugging. However, the book is a bit too verbose.
Displaying 1 - 6 of 6 reviews