Effective Debugging - Big Nerd Ranch Tech Talk

Slide 1

Slide 1 text

Effective Debugging All the techniques and tactics described herein are ways to account for the limited working memory and cognitive power of humans.

Slide 2

Slide 2 text

Deﬁnitions First thing, let’s start with deﬁnitions.

Slide 3

Slide 3 text

What is debugging? We often thinking of debugging as “squashing bugs” but it is actually resolving root causes of symptoms. To summarize, debugging is identifying the root cause of the actual behavior of the system when it differs from the desired behavior.

Slide 4

Slide 4 text

What is effective debugging? Effective debugging is efficiently identifying the root cause of the actual behavior of the system when it differs from the desired behavior.

Slide 5

Slide 5 text

Overview • Deﬁnitions • Have a Process • Know Your Tools • Available Debugging Libraries • Case Study • Recap and advanced commands • Pry

Slide 6

Slide 6 text

Have a Process

Slide 7

Slide 7 text

Have a Process * shamelessly borrowed from Debugging by David Agans

Slide 8

Slide 8 text

Have a Process • Understand the System • Make It Fail • Quit Thinking and Look • Divide and Conquer • Change One Thing at a Time • Keep an Audit Trail • Check the Plug • Get a Fresh View • If You Didn't Fix It, It Ain't Fixed

Slide 9

Slide 9 text

Understand the System Read your bootstrap documentation, application README, tests, and READMEs of any libraries your using. Run the tests even. If this isn’t an API and it has a client side interface, practice using it as a user. ! Once my team spent two days debugging a “memory leak” performance regression because we didn’t know there was a gem that disabled GC!

Slide 10

Slide 10 text

Make it Fail You must be able to reproduce the bug. What is the minimum set of user input and data necessary to reproduce it. If you can’t reproduce it, you won’t be able to verify the root cause or causes ﬁxed it!

Slide 11

Slide 11 text

Quit Thinking and Look Developers well acquainted with an application will often make an assumption and jump to a conclusion as to “what is wrong.” Check your ego and read the error. Read the stack trace. Read the functional spec.

Slide 12

Slide 12 text

Divide and Conquer Binary searches are much faster than a bubble sort. Would you sequentially search through the dictionary for the deﬁnition of a word you’re looking for? NOPE.

Slide 13

Slide 13 text

Change One Thing at a Time Again, these points are all obvious. If you change more than one thing, how can you be sure what ﬁxed?

Slide 14

Slide 14 text

Keep an Audit Trail Terrible bugs may take a terrible amount of time to resolve. If you spend days on a one bug, you need to be clear about what you’ve already tried. This will come in handy in later steps too.

Slide 15

Slide 15 text

Check the Plug Question your assumptions. Work from the outside in. Start from the basics.

Slide 16

Slide 16 text

Get a Fresh View Rubber ducking allows someone else to check your assumptions. They’ll double check your process in a different way. Maybe they’re an expert or have experience in a different area. Two heads are better than one.

Slide 17

Slide 17 text

If You Didn't Fix It, It Ain't Fixed If you forgot or skipped the “Make It Fail” step, you’re not going to know if it was your work that fixed it. Verify that your fix really fixed it.

Slide 18

Slide 18 text

Slide 19

Slide 19 text

Know Your Tools * in Ruby

Slide 20

Slide 20 text

Available Debugger Libraries • 1.8 -- ruby-debug • 1.9 -- debugger, ruby-debug19, debugger2 • 2.0 -- debugger, byebug, debugger2 There’s a lot of options for debuggers in the ruby ecosystem.

Slide 21

Slide 21 text

DEBUGGERS STINK! But not really, it is because..

Slide 22

Slide 22 text

Why? - why? coupling! - let’s take a look at the change log for the debugger gem...

Slide 23

Slide 23 text

No content

Slide 24

Slide 24 text

No content

Slide 25

Slide 25 text

Ruby’s C API - in the past, most debugging tools are tightly coupled to the C internals. - because the debuggers were hooking into internals, every time ruby changed, you needed a new debugger

Slide 26

Slide 26 text

Debugger Versions • 1.8 -- ruby-debug • 1.9 -- debugger, debugger2, ruby-debug19 • 2.0 -- debugger, debugger2, byebug - lag time between new version of ruby and a fully supported debugger - debugger2 / byebug - use external C APIs

Slide 27

Slide 27 text

~/.rdebugrc • set autoreload • set autoeval • set autolist  - for ruby 1.8.7 - if you’re using debugger, byebug or debugger2, these are the defaults

Slide 28

Slide 28 text

Slide 29

Slide 29 text

Slide 30

Slide 30 text

Case Study - use byebug - here’s the situation. - you’ve been handed an existing project by your boss..

Slide 31

Slide 31 text

Slide 32

Slide 32 text

Sacculina Carcini - parasitic barnacle - takes over the host; host no longer molts; male crabs act like female crabs - http://www.ﬂickr.com/photos/81858878@N00/9025250716/in/photolist-eKwLAY

Slide 33

Slide 33 text

- this project has a test suite - previous developer completed feature and hands off a “green” test suite (or so he says)

Slide 34

Slide 34 text

No content

Slide 35

Slide 35 text

No content

Slide 36

Slide 36 text

No content

Slide 37

Slide 37 text

No content

Slide 38

Slide 38 text

- turnip / rspec, explain that steps are executed in order. - execution stops rspec expectation is not met.

Slide 39

Slide 39 text

- not enough information on line 12 to tell us why it failed - let’s look at the stack trace in the rspec output

Slide 40

Slide 40 text

let’s examine the step deﬁnition on line 32 to see if it can tell us more

Slide 41

Slide 41 text

- here we are in the step deﬁnition ﬁle

Slide 42

Slide 42 text

- the internal state of the crab should have a key that points to the parasite - let’s take a step back and review the feature again..

Slide 43

Slide 43 text

- here’s the feature - and we know the failure is on line 12...

Slide 44

Slide 44 text

- but we don’t know when the crab’s payload should have its infection - it could happen on lines 3 through 11..

Slide 45

Slide 45 text

- at this point, it may be tempting to investigate the internal details of the crab class and its payload and how that works but that would be premature at this point. instead of anticipating where the problems lies, we’re going to allow our tool, the debugger, to direct our investigations. we’re not making assumptions as to the root cause of the error. let’s stay “assumption free.” - so, let’s use the ruby gem ‘debugger’..

Slide 46

Slide 46 text

No content

Slide 47

Slide 47 text

- update our gem ﬁle to include a reference to the ‘byebug’ gem

Slide 48

Slide 48 text

- call the debugger method which pauses our application. - but where should we put it?...

Slide 49

Slide 49 text

- there’s no relationship between host, the crab, and parasite, the sacculina carcini

Slide 50

Slide 50 text

- instead, let’s place our debugger statement at the ﬁrst step where the parasite and the host interact. - note that execution is paused on the ruby expression immediately following the debugger method call. - let’s run the debugger

Slide 51

Slide 51 text

No content

Slide 52

Slide 52 text

- let’s take a moment to discuss what we see in the debugger

Slide 53

Slide 53 text

- we see ten lines of context

Slide 54

Slide 54 text

- the line numbers appear in the ﬁrst column

Slide 55

Slide 55 text

- here’s the current line where the application is paused

Slide 56

Slide 56 text

- and that is indicated by the presence of the hash rocket. - great. now we know where we are in the debugger session, let’s examine the code in this step...

Slide 57

Slide 57 text

- we have two lines. - ah, line 12 looks interesting. do you remember what the original failure? it was related to the crab’s payload. - the crab’s payload was nil when the test expected there to be a value - let’s add the crab’s payload as a display (or watched) variable

Slide 58

Slide 58 text

No content

Slide 59

Slide 59 text

No content

Slide 60

Slide 60 text

No content

Slide 61

Slide 61 text

- ﬁrst thing to note is that our displayed ruby expression is still nil - secondly, whoa, where are we..

Slide 62

Slide 62 text

- we’re actually in a new ﬁle. we’re inside the attach method of the parasite. - the debugger command “step” goes into a method deﬁnition. we “step” into

Slide 63

Slide 63 text

- a little different than last time. we provide a number after step. this indicates how many times to run the step command. this is useful when you want to issue the same command multiple times. this will run “step” 3 times for us.

Slide 64

Slide 64 text

No content

Slide 65

Slide 65 text

No content

Slide 66

Slide 66 text

No content

Slide 67

Slide 67 text

No content

Slide 68

Slide 68 text

- yeah, we have a value for the payload

Slide 69

Slide 69 text

- uh oh, where are we?

Slide 70

Slide 70 text

- we’re interested in what happens at the turnip step levels of lines 8, 9, 10 and 11. - how can we quickly stop execution at those lines? ...

Slide 71

Slide 71 text

- well, i can think of one way, we could add ‘debugger’ statements at lines 16, 20, 24, and 28...

Slide 72

Slide 72 text

- so instead of just one debugger statement, we would have ﬁve...

Slide 73

Slide 73 text

- however, there’s a better way. let’s make use of the capabilities provided by the debugger tool.

Slide 74

Slide 74 text

No content

Slide 75

Slide 75 text

No content

Slide 76

Slide 76 text

No content

Slide 77

Slide 77 text

No content

Slide 78

Slide 78 text

No content

Slide 79

Slide 79 text

No content

Slide 80

Slide 80 text

No content

Slide 81

Slide 81 text

No content

Slide 82

Slide 82 text

No content

Slide 83

Slide 83 text

No content

Slide 84

Slide 84 text

No content

Slide 85

Slide 85 text

No content

Slide 86

Slide 86 text

No content

Slide 87

Slide 87 text

No content

Slide 88

Slide 88 text

No content

Slide 89

Slide 89 text

No content

Slide 90

Slide 90 text

No content

Slide 91

Slide 91 text

- here we are at breakpoint 4

Slide 92

Slide 92 text

- the crab payload in our display list hasn’t changed from 0x007

Slide 93

Slide 93 text

- the last time we stepped into a method, we took a detour that wasn’t necessary or informative. - let’s explore another debugger command, ‘next’...

Slide 94

Slide 94 text

No content

Slide 95

Slide 95 text

No content

Slide 96

Slide 96 text

No content

Slide 97

Slide 97 text

- hasn’t changed from 0x007. - but wait, what’s that?!?!

Slide 98

Slide 98 text

- string vs. symbol!

Slide 99

Slide 99 text

No content

Slide 100

Slide 100 text

No content

Slide 101

Slide 101 text

No content

Slide 102

Slide 102 text

No content

Slide 103

Slide 103 text

No content

Slide 104

Slide 104 text

No content

Slide 105

Slide 105 text

No content

Slide 106

Slide 106 text

No content

Slide 107

Slide 107 text

Recap and Advanced Commands - here’s the situation. - you’ve been handed an existing project by your boss..

Slide 108

Slide 108 text

Case Study Recap • debugger • display • step • break • continue • next - debugger is a method that you may place in your application that will pause its execution allowing you to examine state, modify state, set further break points.

Slide 109

Slide 109 text

Case Study Recap • debugger • disp • step • break • next - debugger is a method that you may place in your application that will pause its execution allowing you to examine state, modify state, set further break points.

Slide 110

Slide 110 text

Case Study Recap • debugger • display • step • break • next - also called watch

Slide 111

Slide 111 text

Case Study Recap • debugger • display • step • break • next

Slide 112

Slide 112 text

Case Study Recap • debugger • disp • step • break • next

Slide 113

Slide 113 text

Case Study Recap • debugger • disp[lay] • step • break • next

Slide 114

Slide 114 text

Case Study Recap • debugger • disp[lay] • step [n] • break • next

Slide 115

Slide 115 text

Case Study Recap • debugger • disp[lay] • step • break • next

Slide 116

Slide 116 text

Case Study Recap • debugger • disp[lay] • step • break <ﬁle name>: • next

Slide 117

Slide 117 text

Case Study Recap • debugger • disp[lay] • step • b <ﬁle name>: • next

Slide 118

Slide 118 text

Case Study Recap • debugger • disp[lay] • step • b Class.class_method • next

Slide 119

Slide 119 text

Case Study Recap • debugger • disp[lay] • step • b Class#instance_method • next

Slide 120

Slide 120 text

Case Study Recap • debugger • display • step • break • continue • next - continue execution until the application completes or we hit another breakpoint

Slide 121

Slide 121 text

Case Study Recap • debugger • disp[lay] • step • break • next

Slide 122

Slide 122 text

Case Study Recap • debugger • disp[lay] • step • break • next [n]

Slide 123

Slide 123 text

Case Study Recap • debugger • disp[lay] • step • break • n [n]

Slide 124

Slide 124 text

Advanced Commands • ﬁnish • save • source - what did we miss?

Slide 125

Slide 125 text

What did we miss? • ﬁnish • source

Slide 126

Slide 126 text

- remember in our case study when we were on line eleven and we “stepped” into the attach method on @sacculini_carcini?...

Slide 127

Slide 127 text

- and at that time we stepped 3? - what if we had a loop, or many many lines of code?...

Slide 128

Slide 128 text

- so instead of step, we use “ﬁnish” which execute code until the current stack has completed

Slide 129

Slide 129 text

No content

Slide 130

Slide 130 text

What did we miss? • ﬁnish • save • source

Slide 131

Slide 131 text

No content

Slide 132

Slide 132 text

No content

Slide 133

Slide 133 text

No content

Slide 134

Slide 134 text

No content

Slide 135

Slide 135 text

No content

Slide 136

Slide 136 text

No content

Slide 137

Slide 137 text

No content

Slide 138

Slide 138 text

- automatically evaluate ruby expressions - show full ﬁle paths or just the ﬁlename - - display context - auto start irb when prompt is shown

Slide 139

Slide 139 text

What did we miss? • ﬁnish • save • source

Slide 140

Slide 140 text

No content

Slide 141

Slide 141 text

No content

Slide 142

Slide 142 text

No content

Slide 143

Slide 143 text

No content

Slide 144

Slide 144 text

No content

Slide 145

Slide 145 text

No content

Slide 146

Slide 146 text

Pry • “powerful alternative to [...] IRB [...]” • syntax highlighting • “ﬂexible plugin architecture” - here’s the important thing, PRY is a REPL (read eval print loop) - let’s take a look; two things to do

Slide 147

Slide 147 text

- add pry and pry-byebug to your Gemﬁle

Slide 148

Slide 148 text

No content

Slide 149

Slide 149 text

No content

Slide 150

Slide 150 text

- similar display, column numbers on the left, hash rocket indicates the current line - pretty colors

Slide 151

Slide 151 text

- binding.pry stops us before the binding.pry statement on line 10 so we don’t need “; true”

Slide 152

Slide 152 text

No content

Slide 153

Slide 153 text

- notice we have to use “break”, no shortcuts - and we must use the relative path from the project directory to when specifying the ﬁle

Slide 154

Slide 154 text

- after hitting enter, we see info about the break point...

Slide 155

Slide 155 text

- in addition we see the context too for the break point.

Slide 156

Slide 156 text

No content

Slide 157

Slide 157 text

- pry tells us how often the break point is hit - we have a few more things to note about pry...

Slide 158

Slide 158 text

- no shortcuts for commands unless you deﬁne them

Slide 159

Slide 159 text

Debugger (+ Pry) Versions • 1.9 -- pry + pry-debugger • 2.0 -- pry + pry-byebug

Slide 160

Slide 160 text

Others? • Rubinius? • JRuby?

Slide 161

Slide 161 text

No content

Slide 162

Slide 162 text

- for JRuby, feel free to use any of the Java tools for debugging

Slide 163

Slide 163 text

Other tools? • #source_location • puts '*'*80 • pp • gem which • ap - awesome_print • editor plugins (ctags in vim, cucumber step deﬁnitions)

Slide 164

Slide 164 text

Slides and Code and Image • https://speakerdeck.com/jwallace/effective- debugging-bnr-tech-talk • https://github.com/wallace/ sacculina_carcini.git • http://www.ﬂickr.com/photos/ 81858878@N00/9025250716/in/photolist- eKwLAY

Slide 165

Slide 165 text

Credits and References and Further Reading • http://blog.regehr.org/archives/199 • http://blog.regehr.org/archives/849 • http://www.amazon.com/Debugging-David-J-Agans-ebook/ dp/B002H5GSZ2/ref=sr_1_1? s=books&ie=UTF8&qid=1386325548&sr=1-1&keywords=d ebugging%3A+the+9+indispensable+rules+for+ﬁnding+even +the+most+elusive+software+and+hardware+problems • http://blog.bignerdranch.com/4390-slide-design-developers/ • https://kuler.adobe.com/vintage-card-color-theme-3165833/

Slide 166

Slide 166 text

Get to know me! KNOW ME http://blog.jonathanrwallace.com/about FOLLOW ME @jonathanwallace WORK WITH ME http://www.bignerdranch.com CODE WITH ME github/wallace - thanks to Big Nerd Ranch, organizers and people who helped me with this talk