DOCSLIB.ORG

Debug It! Find, Repair, and Prevent Bugs in Your Code

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
Debug It! Find, Repair, and Prevent Bugs in Your Code What Readers Are Saying About Debug It! Paul does an excellent job of explaining the technical, intellectual, and psychological aspects of all phases of debugging: preventing bugs in the first place, diagnosing and fixing bugs, and making sure that the same bugs don’t happen again. Applying any or all of the ideas from this book will improve the overall quality of your software projects. Sure, the technical issues are well covered but how Paul also explains the psychological angles is what makes this book exceptional. Frederic Daoud Author, Stripes...and Java Web Development Is Fun Again I wholeheartedly recommend this book to software engineers generally but more specifically to team leads who need to know how to set up their teams for best practice. Allan McLeod Founder and CTO, Isaacc Software Debug It! does a great job of setting the scene for debugging and get- ting you into the right mind-set while also talking about the complica- tions that can arise once the bug is found and squashed. It’s worth a look for the anecdotes alone, to see the lengths that people go to when trying to understand truly bizarre defects. Jon Dickinson Author, Grails 1.1 Web Application Development Debugging has been a folk art for so long that it’s great to have some- one put all the tried-and-true techniques together. Debug It! is the perfect book to pull out when you’re disillusioned with the brain- breaking process of creating good software. With this tool chest of assertions, logging, refactoring, and other good stuff, you’ll feel like you’re Sherlock Holmes and solving the case is inevitable. Craig Riecke Author, Mastering Dojo: JavaScript and Ajax Tools for Great Web Experiences This book is like a companion volume to The Pragmatic Programmer, applying the same focus on craftsmanship to the debugging process. Ian Dees Author, Scripted GUI Testing with Ruby Paul Butcher has brought long overdue attention to the methods of debugging, a fundamental activity for every software developer yet one that remains an exercise of intuition and guesswork for most in the profession. Paul’s gentle writing style belies the discipline in his tech- nique. Before you know it, you’ll be an engineer instead of a hacker. Bill Karwin Software Engineer, Karwin Software Solutions, LLC Debug It! Find, Repair, and Prevent Bugs in Your Code Paul Butcher The Pragmatic Bookshelf Raleigh, North Carolina Dallas, Texas Many of the designations used by manufacturers and sellers to distinguish their prod- ucts are claimed as trademarks. Where those designations appear in this book, and The Pragmatic Programmers, LLC was aware of a trademark claim, the designations have been printed in initial capital letters or in all capitals. The Pragmatic Starter Kit, The Pragmatic Programmer, Pragmatic Programming, Pragmatic Bookshelf and the linking g device are trademarks of The Pragmatic Programmers, LLC. Every precaution was taken in the preparation of this book. However, the publisher assumes no responsibility for errors or omissions, or for damages that may result from the use of information (including program listings) contained herein. Our Pragmatic courses, workshops, and other products can help you and your team create better software and have more fun. For more information, as well as the latest Pragmatic titles, please visit us at http://www.pragprog.com Copyright © 2009 Paul Butcher. All rights reserved. No part of this publication may be reproduced, stored in a retrieval system, or transmit- ted, in any form, or by any means, electronic, mechanical, photocopying, recording, or otherwise, without the prior consent of the publisher. Printed in the United States of America. ISBN-10: 1-934356-28-X ISBN-13: 978-1-934356-28-9 Printed on acid-free paper. P1.0 printing, November 2009 Version: 2009-11-4 Contents Preface 10 About This Book .......................... 10 Acknowledgments .......................... 11 I The Heart of the Problem 13 1 A Method in the Madness 14 1.1 Debugging Is More Than “Making the Bug Go Away” . 14 1.2 The Empirical Approach .................. 16 1.3 The Core Debugging Process ............... 17 1.4 First Things First ...................... 18 1.5 Put It in Action ....................... 22 2 Reproduce 23 2.1 Reproduce First, Ask Questions Later .......... 23 2.2 Controlling the Software .................. 25 2.3 Controlling the Environment ............... 26 2.4 Controlling Inputs ..................... 28 2.5 Refining Your Reproduction ................ 36 2.6 What If You Really Can’t Reproduce It? ......... 45 2.7 Put It in Action ....................... 48 3 Diagnose 49 3.1 Stand Back—I’m Going to Try Science .......... 49 3.2 Stratagems .......................... 56 3.3 Debuggers .......................... 62 3.4 Pitfalls ............................ 63 3.5 Mind Games ......................... 67 3.6 Validate Your Diagnosis .................. 72 3.7 Put It in Action ....................... 73 CONTENTS 8 4 Fix 74 4.1 Clearing the Decks ..................... 75 4.2 Testing ............................ 76 4.3 Fix the Cause, Not the Symptoms ............ 78 4.4 Refactoring .......................... 80 4.5 Checking In ......................... 82 4.6 Get Your Code Reviewed .................. 83 4.7 Put It in Action ....................... 84 5 Reflect 85 5.1 How Did It Ever Work? ................... 85 5.2 What Went Wrong? ..................... 86 5.3 It’ll Never Happen Again .................. 89 5.4 Close the Loop ........................ 92 5.5 Put It in Action ....................... 93 II The Bigger Picture 94 6 Discovering That You Have a Problem 95 6.1 Tracking Bugs ........................ 95 6.2 Working with Users ..................... 100 6.3 Working with Support Staff ................ 105 6.4 Put It in Action ....................... 107 7 Pragmatic Zero Tolerance 108 7.1 Bugs Take Priority ..................... 108 7.2 The Debugging Mind-Set .................. 111 7.3 Digging Yourself Out of a Quality Hole .......... 113 7.4 Put It in Action ....................... 118 III Debug-Fu 119 8 Special Cases 120 8.1 Patching Existing Releases ................ 120 8.2 Backward Compatibility .................. 121 8.3 Concurrency ......................... 126 8.4 Heisenbugs ......................... 128 8.5 Performance Bugs ..................... 130 8.6 Embedded Software ..................... 132 8.7 Bugs in Third-Party Software ............... 135 8.8 Put It in Action ....................... 140 CONTENTS 9 9 The Ideal Debugging Environment 141 9.1 Automated Testing ..................... 141 9.2 Source Control ....................... 144 9.3 Automatic Builds ...................... 149 9.4 Put It in Action ....................... 157 10 Teach Your Software to Debug Itself 158 10.1 Assumptions and Assertions ............... 158 10.2 Debugging Builds ...................... 168 10.3 Resource Leaks and Exception Handling ........ 173 10.4 Put It in Action ....................... 180 11 Anti-patterns 181 11.1 Priority Inflation ....................... 181 11.2 Prima Donna ......................... 182 11.3 Maintenance Team ..................... 184 11.4 Firefighting .......................... 186 11.5 Rewrite ............................ 187 11.6 No Code Ownership ..................... 189 11.7 Black Magic ......................... 189 11.8 Put It in Action ....................... 190 A Resources 192 A.1 Source Control and Issue-Tracking Systems . 192 A.2 Build and Continuous Integration Tools ......... 195 A.3 Useful Libraries ....................... 197 A.4 Other Tools ......................... 199 B Bibliography 203 Index 205 Preface I’ve always been mystified why so few books are available on debugging. You can buy any number on every other aspect of software engineering such as design, code construction, requirements capture, methodolo- gies...the list is endless. And yet, for some reason, debugging has been almost (not quite but very nearly) ignored by authors and publishers. I hope that this book can help remedy the situation. If you write code, it’s a certainty that at some point (possibly very soon afterward) you’re going to have to debug it. Debugging is, more than anything else, an intellectual process—it doesn’t take place within a debugger or your code but inside your mind. Reaching an understand- ing of the root cause of the problem is the cornerstone upon which everything else depends. Over the years, I’ve been fortunate to work with a number of incredi- bly talented teams on a wide range of software. I’ve worked at all levels of abstraction from microcode on bit-slice processors through device drivers, embedded code, mainstream desktop software, and web appli- cations. I hope that I can pass along some of the lessons I’ve learned from my colleagues along the way. About This Book This book is divided into three parts, each of which considers a partic- ular aspect of debugging: “The Heart of the Problem”: This part introduces the empirical approach, which leverages our software’s unique ability to show us what’s going on, and the core debugging method (reproduce, diagnose, fix, reflect) that relies upon it. ACKNOWLEDGMENTS 11 “The Bigger Picture”: How do we find out that there’s a problem that needs fixing in the first place? And how does debugging integrate into the wider software development process? “Debug-Fu”: In the third and final part, we’ll turn our attention to a number of advanced topics: • Although the approaches discussed earlier in the book apply to all bugs, certain types of bugs benefit from special treat- ment. • Debugging starts long
Load more

Recommended publications
  • Congressional Record United States Th of America PROCEEDINGS and DEBATES of the 113 CONGRESS, FIRST SESSION
    E PL UR UM IB N U U S Congressional Record United States th of America PROCEEDINGS AND DEBATES OF THE 113 CONGRESS, FIRST SESSION Vol. 159 WASHINGTON, TUESDAY, SEPTEMBER 24, 2013 No. 127—Part II Senate MAKING CONTINUING APPROPRIA- Mr. KAINE. So the Senator will not other State and another race between TIONS FOR FISCAL YEAR 2014— vote to continue government oper- two candidates, where one candidate MOTION TO PROCEED—Continued ations unless ObamaCare is defunded? took the strong position that Mr. CRUZ. The Senator from Vir- ObamaCare should be repealed and the In the Senator’s view, is it acceptable ginia is correct, and I have stated that other candidate took the strong posi- for the discussion of a government I will not vote for a continuing resolu- tion that ObamaCare should not be re- shutdown to threaten the nonmilitary tion that funds ObamaCare. I believe pealed. In that State, the candidate priorities that are important to the this body should not vote for a con- that won by a sizable margin was the American public? tinuing resolution that funds candidate who said ObamaCare should Mr. CRUZ. I appreciate the question ObamaCare. Why? Because the facts not be repealed, having been plain from the Senator from Virginia. I show it is not working. about it with the voters, and the voters would note, I do not think we should That is why the unions that used to having heard the choices and made a shut anything down except ObamaCare. support it are, one after the other, choice. Does the Senator think it is I think we should fund it all.
    [Show full text]
  • Global Christian Shifts and Missional Church Movements: Linking the Postcolonial Global South with the Postmodern West Stephen P
    Digital Commons @ George Fox University Doctor of Ministry Theses and Dissertations 4-1-2009 Global Christian Shifts and Missional Church Movements: Linking the Postcolonial Global South with the Postmodern West Stephen P. Lewis This research is a product of the Doctor of Ministry (DMin) program at George Fox University. Find out more about the program. Recommended Citation Lewis, Stephen P., "Global Christian Shifts nda Missional Church Movements: Linking the Postcolonial Global South with the Postmodern West" (2009). Doctor of Ministry. 323. https://digitalcommons.georgefox.edu/dmin/323 This Dissertation is brought to you for free and open access by the Theses and Dissertations at Digital Commons @ George Fox University. It has been accepted for inclusion in Doctor of Ministry by an authorized administrator of Digital Commons @ George Fox University. For more information, please contact [email protected]. GEORGE FOX UNIVERSITY GLOBAL CHRISTIAN SHIFTS AND MISSIONAL CHURCH MOVEMENTS: LINKING THE POSTCOLONIAL GLOBAL SOUTH WITH THE POSTMODERN WEST A DISSERTATION SUBMITTED TO THE FACULTY OF GEORGE FOX EVANGELICAL SEMINARY IN CANDIDACY FOR THE DEGREE OF DOCTOR OF MINISTRY BY STEPHEN P. LEWIS NEWBERG, OREGON APRIL 2009 PORTLAND CENTER LIBRARY GEORGE FOX UNIVERSITY PORTLAND, OR. 97223 DISSERTATION ACCEPTANCE CERTIFICATE STEPHEN P. LEWIS DATE: MARCH 1 1, 2009 TITLE: GLOBAL CHRISTIAN SHIFTS AND MISSIONAL CHURCH MOVEMENTS: LINKING THE POSTCOLONIAL GLOBAL SOUTH WITH THE POSTMODERN WEST WE THE UNDERSIGNED CERTIFY THAT WE HAVE READ THIS PROJECT AND APPROVE IT AS ADEQUATE IN SCOPE AND QUALITY TO COMPLETE THE REQUIREMENTS FOR THE DOCTOR OF MINISTRY IN LEADERSHIP IN THE EMERGING CULTURE DEGREE GEoRGE Fox l'VANGEI.lCAl.
    [Show full text]
  • Fixing Complex Faults in Embedded Cyberphysical Systems
    Understanding and Fixing Complex Faults in Embedded Cyberphysical Systems PREPRINT IEEE COMPUTER MAGAZINE, JANUARY 2021 Alexander Weiss*, Smitha Gautham**, Athira Varma Jayakumar**, Carl Elks**, D. Richard Kuhn***, Raghu N. Kacker***, Thomas B. Preusser* * Accemic Technologies ** Virginia Commonwealth University *** National Institute of Standards and Technology Understanding fault types can lead to novel approaches to debugging and runtime verification. Dealing with complex faults, particularly in the challenging area of embedded systems, craves for more powerful tools, which are now becoming available to engineers. MISTAKES, ERRORS, DEFECTS, BUGS, FAULTS AND ANOMALIES Embedded systems are everywhere, and they present unique challenges in verification and testing. The real-time nature of many embedded systems produces complex failure modes that are especially hard to detect and prevent. To prevent system failures, we need to understand the nature and common types of software anomalies. We also need to think about how mistakes lead to observable anomalies and how these can be differentiated according to their reproducibility. Another key need for efficient fault detection is the comprehensive observability of a system. This kind of understanding leads to the principle of "scientific debugging". In everyday language, we use a number of words such as bug, fault, error, etc. inconsistently and confusingly to describe the malfunctioning of a software-based system. This also happens to the authors of this paper in their normal life unless they pay strict attention to their choice of words. Therefore, we would like to start with a brief clarification based on the terminology used by the "IEEE Standard Classification for Software Anomalies" [1]. • If coders notice a mistake themselves, it is called an error (“a human action that produces an incorrect result “[1]).
    [Show full text]
  • Software Debugging Techniques
    Software debugging techniques P. Adragna Queen Mary, University of London Abstract This lecture provides an introduction to debugging, a crucial activity in ev- ery developer's life. After an elementary discussion of some useful debugging concepts, the lecture goes on with a detailed review of general debugging tech- niques, independent of any specific software. The final part of the lecture is dedicated to analysing problems related to the use of C++ , the main program- ming language commonly employed in particle physics nowadays. Introduction According to a popular definition [1], debugging is a methodical process of finding and reducing the number of bugs, or defects, in a computer program. However, most people involved in spotting and removing those defects would define it as an art rather then a method. All bugs stem from a one basic premise: something thought to be right, was in fact wrong. Due to this simple principle, truly bizarre bugs can defy logic, making debugging software challenging. The typical behaviour of many inexperienced programmers is to freeze when unexpected problems arise. Without a definite process to follow, solving problems seems impossible to them. The most obvious reaction to such a situation is to make some random changes to the code, hoping that it will start working again. The issue is simple: the programmers have no idea of how to approach debugging [2]. This lecture is an attempt to review some techniques and tools to assist non-experienced pro- grammers in debugging. It contains both tips to solve problems and suggestions to prevent bugs from manifesting themselves. Finding a bug is a process of confirming what is working until something wrong is found.
    [Show full text]
  • 1 Software Needs Seatbelts and Airbags
    DEBUGGING Software Needs Seatbelts and Airbags Finding and fixing bugs in deployed software is difficult and time-consuming. Here are some alternatives. Emery D. Berger, University of Massachusetts, Amherst Like death and taxes, buggy code is an unfortunate fact of life. Nearly every program ships with known bugs, and probably all of them end up with bugs that are discovered only post-deployment. There are many reasons for this sad state of affairs. One problem is that many applications are written in memory-unsafe languages. Variants of C, including C++ and Objective-C, are especially vulnerable to memory errors such as buffer overflows and dangling pointers (use-after-free bugs). Two of these are in the SANS Top 25 list: buffer copy without checking size of input (http://cwe.mitre.org/top25/index.html#CWE-120) and incorrect calculation of buffer size (http://cwe.mitre.org/top25/index.html#CWE-131); see also heap-based buffer overflow (http://cwe.mitre.org/data/definitions/122.html) and use after free (http://cwe.mitre. org/data/definitions/416.html). These bugs, which can lead to crashes, erroneous execution, and security vulnerabilities, are notoriously challenging to repair. SAFE LANGUAGES: NO PANACEA Writing new applications in memory-safe languages such as Java instead of C/C++ would help mitigate these problems. For example, because Java uses garbage collection, Java programs are not susceptible to use-after-free bugs; similarly, because Java always performs bounds-checking, Java applications cannot suffer memory corruption caused by buffer overflows. That said, safe languages are no cure-all. Java programs still suffer from buffer overflowsand null pointer dereferences, although they throw an exception as soon as they happen, unlike their C-based counterparts.
    [Show full text]
  • Pareon Verify
    Pareon Verify Test suite for dynamic Find the hard-to-fi nd errors software verifi cation other tools don’t fi nd “We are going to defi nitely incorporate the Vector Fabrics toolset as an important part of our quality off ering“ Jan Asselman Quality team leader / Altran Intelligent Systems Copyright © 2015 Vector Fabrics B.V Avoid software errors and high repair costs with Pareon Verify Test suite for dynamic software verification finds difficult-to-detect software errors and makes lengthy debugging sessions a thing of the past. The amount of software in embedded Cost of an error systems, cell phones, or transportation vehicles such as cars and airplanes is A study by NASA [1] shows the cost of fixing a software error found in the field is 100x more expensive than exploding in size and importance. This the same error found already during development. development has led to a exponential growth in the number of potential software errors or “bugs”. It is more important than ever to effectively and thoroughly test software before it is shipped. With the common use of C++ nowadays, it is also common to have more dynamic behavior and multithreading. This leads to a new category of errors that is hard to detect using the traditional testing tools and methods. Development Testing In the field Errors are expensive The mounting costs of a software defect. Having to repair software errors post-release in pro- duction or in the field is a costly process. Expensive, even without taking into account any damage to the brand and the public image of the manufacturer.
    [Show full text]
  • Trinitarian God Creation Human Image Bearers the Fall Broken
    DTS Reframe YOU ARE HERE Trinitarian God Creation The Fall Children of Abraham Jesus Christ Spirit & Church Jesus Returns Human Image Bearers Broken Image Bearers Covenant Image The True Image Bearer YWAM‐DTS Kingdom/New Creation Bearers Failed Renewed Image Jesus Reigns with Bearers Restored Image Bearers 2 Index The DTS and YWAM are Embedded in God’s Story…….…………..p.6 Facilitating a Discipleship Community……………….………………..….……p.7 Facilitating Discipleship in the DTS Community………………..……..p.11 Designing Your DTS………………………………………………………………………….…..p.15 DTS Reframe Curriculum………………………………………………….………………..p.38 Engaging with the Curriculum Categories………………..…………………p.40 DTS Design Samples…………………………………………………………………………….p.61 Appendix………………………………………………………………………………………………….p.71 Index: 3 Facilitating a Discipleship Community & Designing Your DTS Facilitating a Discipleship Community……p.7 Designing Your DTS…………….............……………...p.15 • Practice the YWAM Values in • The Purpose of the DTS……………………....…p.16 Base and School Community………..........p.8 • Designing the DTS Including • Facilitating Discipleship in the Corporate Practices…………………..…….….....p.18 DTS Community………………………………..…......p.11 • Corporate Practices in the DTS to Facilitate Discipleship…………………..……p.32 • Sample DTS Weekly Schedule with Weekly Corporate Practices……....p.35 • Sample DTS Lecture Phase with Occasional Corporate Practices...p.36 • Sample DTS Outreach Schedule with Corporate Practices………………….......p.37 Index: 4 Curriculum Categories DTS Reframe Curriculum……………….....…..….p.38 What went
    [Show full text]
  • Trinitarian Prayer
    2 Introduction to Pilgrim Groups The spiritual disciplines create a path from our physical world into the new world of the Kingdom of God; a world which is breaking in around us. On this path, we learn to think about and respond rightly to God. We open space in our lives to become aware of God interacting with us. We begin to see His beauty unfolding in and around us, and His work accomplished through us. This is the pilgrimage we are presently undertaking. This Village journey has several objectives: first, to further develop community within the Village. Pilgrim Groups are a specific discipleship structure of the Village, and we ask that people who participate in them be active participants in the community, attending worship services at the Village and so forth during their time in the Pilgrim Group. Within this context, the Pilgrim Group is designed for the practice of some of the disciplines of the faith together (these may vary depending on the topic & structure of the particular study & group); to discuss our sexuality in healthy ways; to confess sin, pray for each other, and experience healing; to develop leaders; to grow in knowledge and application of the Bible; and finally, to further the discussion of our vocation in the Kingdom of God. The Discussion... In response to another person’s sharing, group members should refrain from giving advice or telling their own stories as a way of instruction. This is a time to pursue one another by asking open-ended questions and practicing active listening. Try to use clarifying statements like, “What do you mean by _____?” or, “Tell me more about _____.” Instead of offering answers to people’s problems, consider praying together with the laying on of hands as a default solution.
    [Show full text]
  • Debugging Petascale HPC Applications
    Debugging Petascale HPC Applications Blue Waters User Workshop 2013 Objectives ● Raise awareness ● Debugging in general ● Allinea DDT in particular ● Enhance dexterity ● Allinea DDT in particular Print statement debugging? ● The first debugger: print statements ● Each process prints a message or value at defined f(x)Segfault locations Line ● Line Diagnose the problem from x evidence and intuition Number Print ● A long slow process Statements ● Analogous to bisection root finding ● Broken at modest scale ● Too much output – too many log files "Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it." Brian Kernighan Bugs in Practice Some Types of Bugs ● Bohr bug ● Steady, dependable bug ● Heisenbug ● Vanishes when you try to debug (observe) ● Mandelbug ● Complexity and obscurity of the cause is so great that it appears chaotic ● Schroedinbug ● First occurs after someone reads the source file and deduces that it never worked, after which the program ceases to work A `New' Vernacular for Bugs ● Defect ● An incorrect program code – A bug in the code ● Infection ● An incorrect program state – A bug in the state ● Failure ● An observable incorrect program behaviour – A bug in the behaviour Zeller A., “Why Programs Fail”, 2nd Edition, 2009 TRAFFIC ● Debugging ● Transforming a broken program into a working one ● How? ● Track the problem ● Reproduce ● Automate - (and simplify) the test case ● Find origins – where could the “infection” be from? ● Focus – examine the origins ● Isolate – narrow down the origins ● Correct – fix and verify the testcase is successful Zeller A., “Why Programs Fail”, 2nd Edition, 2009 How to Focus and Isolate ● A scientific process? ● Hypothesis, trial and observation, ..
    [Show full text]
  • The Judgment of Procedural Rhetoric
    THE JUDGMENT OF PROCEDURAL RHETORIC A Thesis Presented to The Academic Faculty by Simon Ferrari In Partial Fulfillment of the Requirements for the Degree Master of Digital Media in the School of Literature, Communication, and Culture Georgia Institute of Technology May 2010 COPYRIGHT 2010 BY SIMON FERRARI THE JUDGMENT OF PROCEDURAL RHETORIC Approved by: Dr. Ian Bogost, Advisor Dr. Celia Pearce School of Literature, Communication, and School of Literature, Communication, Culture and Culture Georgia Institute of Technology Georgia Institute of Technology Dr. D. Fox Harrell School of Literature, Communication, and Culture Georgia Institute of Technology Dr. Michael Nitsche School of Literature, Communication, and Culture Georgia Institute of Technology Date Approved: April 05, 2010 To my grandfather, Albert Ferrari, who bought me a Nintendo when I was two years old, worked three jobs so that I could grow up to be whoever I wanted to be, and remembered my name in the throes of Alzheime ACKNOWLEDGMENTS I would like to thank my graduate advisor, Professor Ian Bogost, for taking me under his wing from the first day I came to Georgia Tech forward. It is somewhat inconceivable that I could have made it this far without his guidance. Special thanks go to my friends Bobby Schweizer and Charles Pratt, who pointed me in the direction of ideas that helped hone my thoughts. Secondly, many thanks to my parents for supporting my decision to pursue videogame studies as a career despite their genetically attributed desire for me to someday become a doctor or lawyer. Finally, I’d like to thank Sarah for her continued love and good humor.
    [Show full text]
  • Sri-Aurobindo-Lyrical-Poems
    i Contents One Day ................................................................................................................................. 1 In Horis Aeternum ................................................................................................................. 2 Trance .................................................................................................................................... 3 The Bird of Fire ..................................................................................................................... 4 Shiva ...................................................................................................................................... 6 The Life Heavens ................................................................................................................... 8 Symbol Moon ...................................................................................................................... 12 The World Game ................................................................................................................. 14 Trance of Waiting ................................................................................................................ 17 Jivanmukta ........................................................................................................................... 18 Moon of Two Hemispheres ................................................................................................. 20 Thought the Paraclete .........................................................................................................
    [Show full text]
  • MCFLY: Time-Travel Debugging for the Web
    MCFLY: Time-Travel Debugging for the Web John Vilk, Emery D. Berger James Mickens Mark Marron University of Massachusetts Amherst Harvard University Microsoft Research fjvilk, [email protected] [email protected] [email protected] Abstract Time-traveling debuggers offer the promise of simplifying debugging by letting developers freely step forwards and backwards through a program’s execution. However, web applications present multiple challenges that make time- travel debugging especially difficult. A time-traveling de- bugger for web applications must accurately reproduce all network interactions, asynchronous events, and visual states observed during the original execution, both while stepping Figure 1. All major web browsers separate web applica- forwards and backwards. This must all be done in the con- tion computation (JavaScript engine) from I/O (Layout text of a complex and highly multithreaded browser runtime. Engine). MCFLY both synchronizes and maintains visibil- At the same time, to be practical, a time-traveling debugger ity into the items shown in gray (the JavaScript engine, the must maintain interactive speeds. multithreaded layout engine, and the screen), all at interac- This paper presents MCFLY, the first time-traveling de- tive speed. bugger for web applications. MCFLY departs from previous approaches by operating on a high-level representation of the browser’s internal state. This approach lets MCFLY provide accurate time-travel debugging—maintaining JavaScript driven settings like the web, bug symptoms can manifest far and visual state in sync at all times–at interactive speeds. from their root causes. MCFLY’s architecture is browser-agnostic, building on web There are two widely used approaches to find these bugs: standards supported by all major browsers.
    [Show full text]