Alfresco TTL#157 - Troubleshooting Made Easy: Deciphering Alfresco mTLS Confi...
We Make Debugging Sucks Less
1. Debugging Sucks – We Make
it Suck Less
Alon Fliess
Chief Software Architect
alonf@oz-code.com
http://alonfliess.me
http://oz-code.com
2. About Me
• Alon Fliess:
• Chief Software Architect & Co-Founder at OzCode.
• More than 30 years of hands-on experience
• Many of them in hunting nasty bugs
• Microsoft Regional Director & Microsoft MVP
• Renowned speaker at both international and domestic events
4. How Much Does a Software Bug Cost?
NASA’s Mars Climate
Orbiter
$125 Millions
Ariane 5 Flight 501
$370 Millions
The Mariner 1 Spacecraft
$18 Millions
Heathrow Terminal 5
Opening
$125 Millions
Pentium FDIV bug
$475 Millions
Knight’s $440 Million
Error
$440 Millions
6. Agenda
• Introduction
• Debugging – Overview
• The debugging process
• Debugger internals
• Controlling the debugger – A magical debugging show
• The future of debugging
• Summary
6
7. Wikipedia
• “Debugging is the process of finding and resolving bugs or defects
that prevent correct operation of computer software or a system”
• The terms "bug" and "debugging" are popularly attributed to Admiral
Grace Hopper in the 1940s
• However the term is much older:
• Thomas Edison wrote the following words in a letter to an associate in 1878:
• “It has been just so in all of my inventions. The first step is an intuition, and comes with a
burst, then difficulties arise — this thing gives out and [it is] then that
"Bugs" — as such little faults and difficulties are called — show themselves and months
of intense watching, study and labor are requisite before commercial success or failure is
certainly reached”
12/1/2014 7
8. The Art of Debugging
• Debugging requires:
• Deep understanding of your code
• Deep understanding of your system, environment and tools
• Abstraction layers are great for development, however
when debugging you need to dig under the hood
• Technician senses and techniques
• Gathering evidence
• Analyzing
• Trying
• Hacking
• Patching 8
9. The Debugging Process Overview
•Understand the context & the requirements
• Distinguish bugs and features (By Design)
•Reproduce the bug, make it fail
•Simplify the test case
•Understand the error
•Check the obvious, check the plug
• Can’t write to a read only file
10. The Debugging Process Overview
•Separate facts from interpretation
• Wrong interpretation leads to a dead-end
•Divide and conquer
• Trap the bug in the corner
•Use the right tool for the bug & the context
•Isolate changes - do one change at a time
• See its effect (fact), draw a conclusion (interpretation)
11. The Debugging Process Overview
•Consult others
•Consult your Co-workers
•Get a fresh view
•Use Google, Bing, or any web search engine
•Use Twitter, Stack Overflow or any other social
media
•Search for known bugs and issues
12. The Debugging Process Overview
•Bugs do not disappear
•If you didn’t fix it, it is not fixed
•If you can’t reproduce it anymore, look for what
you or others have changed
•Use Source Control
• You can create a branch for the debugging process
14. Restarting debug run
• After code change
• When we’ve missed crucial information
Manually stepping through the code line-by-line
Breaking on irrelevant spots
How we waste time during debugging
15. Summary
•Like any other development skill, debugging is a skill
that you need to learn
•Real bugs are hard to find and solve
•Be organized, use a debugging process
•Use the right tools, consult with other people,
document the process & tell the world
16. .NET Debugger Options
• Visual Studio
• With OzCode!
• MDbg.exe - .NET Command line Debugger
• WinDbg + SOS.DLL|SOSEX.DLL
16
17. Debugger Anatomy
Wait for
debug event
Handle
debug event
Continue
debug event
Start the debuggee
or attach to it
Enter main
debugger loop
18. Debugger Main Loop
1. …
2. for(;;)
3. {
4. WaitForDebugEvent(DebugEv, INFINITE);
5. switch (DebugEv->dwDebugEventCode)
6. {
7. case EXCEPTION_DEBUG_EVENT:
8. switch(DebugEv->u.Exception.ExceptionRecord.
9. ExceptionCode)
10. {
11. case EXCEPTION_ACCESS_VIOLATION:
12. case …
13. }
19. Debugger Main Loop
1. break;
2. case CREATE_THREAD_DEBUG_EVENT:
3. dwContinueStatus =
4. OnCreateThreadDebugEvent(DebugEv);
5. break;
6. …
7. }
8. // Resume executing the thread that reported the
9. debugging event.
10. ContinueDebugEvent(DebugEv->dwProcessId,
11. DebugEv->dwThreadId,
12. dwContinueStatus);
13. }}
Demo
20. .NET Debugger Anatomy
• The .NET CLR wrap the native debugging API and provides a COM interface for the CLR
debugger:
• There are other debugging interfaces
20
ICorDebug Methods Description
ICorDebug::CanLaunchOrAttach Determines whether launching a new process or attaching is possible
ICorDebug::CreateProcess Launches a process and its primary thread under the control of the debugger
ICorDebug::DebugActiveProcess Attaches the debugger to an existing process.
ICorDebug::EnumerateProcesses Gets an enumerator for the processes that are being debugged
ICorDebug::GetProcess Returns the ICorDebugProcess object with the given process ID
ICorDebug::Initialize Initializes the ICorDebug object.
ICorDebug::SetManagedHandler Specifies the event handler object for managed events
ICorDebug::SetUnmanagedHandler Specifies the event handler object for unmanaged events
ICorDebug::Terminate Terminates the ICorDebug object.
21. Concord – The Visual Studio Debug Engine
• Documentation and Samples are
available online
• Use it to extend the Visual Studio
debugger
• Use it to develop your programming
language debugger
21
22. Controlling the Debugger
• There are two types of (human) debuggers:
• The: I am too tired to think let the debugger lead and control
• The “everything is under control type”
22
23. Controlling the Debugger – The Execution Context
• A debuggee stops its execution when the debugger receives
a debug event
• New thread, load library, exception or special exception such as
breakpoint
• When the debuggee is paused, the debugger pauses all
other threads and the execution context points to
• The current process, current thread, current stack location, current
instruction pointer
• You can change the context in several ways
23
24. Controlling the Execution Context
• Using the debugger UI, you can switch between processes,
threads, and stack locations
• Within the current context of the process and thread:
• Moving the instruction pointer to
• Skip code
• Re-run code
• Setting variable values that control the execution path
• Expressions in if, switch, loop conditions
• Using Edit & Continue
24
26. Method Breakpoints
• If you type a method name (without class name)
• VS select all that matches
.NET Performance & Debugging 26
27. The Scientific Method
• while (still_not_fixed)
• Make it fail
• Trial and error
• Trap and isolate the bug
• Add new unit tests
• Make a hypothesis
• Collect evidence
• Prove or refine the hypothesis
• Refine the unit tests
• Fix the bug
• Run all (regression) tests
• Check-in, document 27
Identify the Bug
• Use source control and
change sets
• Divide & Conquer
• Create a simple case
• The bug is yours, unless you
find it on the Web
• In rare cases – It is other
fault
29. There are some moments in life…
•After which, life is no longer the same!
• The first kiss
• Your wedding
• The first child
• The first time you saw OzCode
29
31. 31
Demo
• Reveal
• Heads Up Display
• Magic Glance
• Search
• Breakpoints
• All Members
• Conditional
• “Property”
• Exception Trail / HUD
OzCode Main Features
32. Collecting Evidence
•Collect program execution data:
• Application log – need to instrument the code
• The Immediate / Command Window
• With >log
• Tracepoints
• With OzCode
• VS Watch Window / OzCode Watch Window
• VS Data Tips / OzCode Data Tips
32
33. 33
Demo
Logging the Immediate & Command
Window – A VS Tip!
> Log "file path"
Optional Switches:
/on Append
/off Close file, stop logging
/overwrite Start new log file
> open "file path"
35. Tracing with Tracepoints
• Can print out any expression by surrounding with {}
• property/field/method call
• Special code can be used:
35
Tracepoint variable name Meaning
$ADDRESS Current instruction address
$CALLER Caller name of current method
$CALLSTACK The call stack at the current location
$FUNCTION Current function name
$PID Current process ID
$PNAME Current process name
$TID Current thread ID
$TNAME Current thread name
37. OzCode Analysis Tools
•Finding problems in vast amount of data is hard
• You need to:
• Navigate the execution context to the right spot
• Analyze and understand LINQ queries
• Analyze and understand code execution (algorithm)
• Filter:
• The properties that are important to you
• The instances in a collection that point to the problem
• Compare object & collection state
• Save “good” state for future comparisons
• Create your own “custom expression” to surface problems
37
38. 38
Demo
OzCode Analysis Tools
• LINQ Analysis
• Compare:
• Two objects or More
• Saved state
• Collection Filtering (next slides)
• Custom Expression (next slides)
43. Summary
• Debugging – Overview
• The debugging process
• Debugger internals
• Controlling the debugger – A
magical debugging show
• The future of debugging
43
1. Understand the requirements
2. Make it fail
3. Simplify the test case
4. Read the right error message
5. Check the plug
6. Separate facts from interpretation
7. Divide and conquer
8. Match the tool to the bug
9. One change at a time
10. Keep an audit trail
11. Get a fresh view
12. If you didn’t fix it, it ain’t fixed
13. Cover your bugfix with a regression test
1. Understand the requirements
2. Make it fail
3. Simplify the test case
4. Read the right error message
5. Check the plug
6. Separate facts from interpretation
7. Divide and conquer
8. Match the tool to the bug
9. One change at a time
10. Keep an audit trail
11. Get a fresh view
12. If you didn’t fix it, it ain’t fixed
13. Cover your bugfix with a regression test
1. Understand the requirements
2. Make it fail
3. Simplify the test case
4. Read the right error message
5. Check the plug
6. Separate facts from interpretation
7. Divide and conquer
8. Match the tool to the bug
9. One change at a time
10. Keep an audit trail
11. Get a fresh view
12. If you didn’t fix it, it ain’t fixed
13. Cover your bugfix with a regression test
1. Understand the requirements
2. Make it fail
3. Simplify the test case
4. Read the right error message
5. Check the plug
6. Separate facts from interpretation
7. Divide and conquer
8. Match the tool to the bug
9. One change at a time
10. Keep an audit trail
11. Get a fresh view
12. If you didn’t fix it, it ain’t fixed
13. Cover your bugfix with a regression test