Fresher Technology Specific - .NET Stream Object-Oriented ...

wakecabbagepatchSoftware and s/w Development

Nov 18, 2013 (3 years and 10 months ago)

85 views

©

FPT SOFTWARE


TRAINING MATERIAL



Int
er
nal
us
e

04e
-
BM/
NS
/HDCV/FSOFT v2
/3

Haipt1
-
HCD.HO

Debugging & Tracing in .NET
Application

©

FPT SOFTWARE


TRAINING MATERIAL



Int
er
nal
us
e

04e
-
BM/
NS
/HDCV/FSOFT v2
/3

Agenda


Debugging technique Theory



Relation to testing



Why debugging is hard



Types of bugs



Process & techniques



How to avoiding bugs


Debugging basic in .NET


The Visual Studio Debugger


Advanced Debugging Scenarios


Tracing


Theory


Tools


Practice


©

FPT SOFTWARE


TRAINING MATERIAL



Int
er
nal
us
e

04e
-
BM/
NS
/HDCV/FSOFT v2
/3

Overview


Debugging is a black art. Some things to go over,
though, so they’ll be concrete in our brains:


relation to testing


why debugging is hard


types of bugs


process


techniques


tools


avoiding bugs

©

FPT SOFTWARE


TRAINING MATERIAL



Int
er
nal
us
e

04e
-
BM/
NS
/HDCV/FSOFT v2
/3

Debugging and testing


Testing and debugging go together like peas in a
pod:


Testing
finds

errors; debugging localizes and
repairs

them.


Together these form the “testing/debugging cycle”: we
test, then debug, then repeat.


Any debugging should be followed by a reapplication of
all

relevant tests, particularly regression tests. This
avoids (reduces) the introduction of new bugs when
debugging.


Testing and debugging need not be done by the same
people (and often should not be).

©

FPT SOFTWARE


TRAINING MATERIAL



Int
er
nal
us
e

04e
-
BM/
NS
/HDCV/FSOFT v2
/3

Why debugging is hard


There may be no obvious relationship between the external
manifestation(s) of an error and its internal cause(s).


Symptom and cause may be in remote parts of the
program.


Changes (new features, bug fixes) in program may mask (or
modify) bugs.


Symptom may be due to human mistake or
misunderstanding that is difficult to trace.


Bug may be triggered by rare or difficult to reproduce input
sequence, program timing (threads) or other external
causes.


Bug may depend on other software/system state, things
others did to you systems weeks/months ago.

©

FPT SOFTWARE


TRAINING MATERIAL



Int
er
nal
us
e

04e
-
BM/
NS
/HDCV/FSOFT v2
/3


when you write code think about how you are
going to test/debug it

-
lack of thought
always

translates into bugs


write test cases when you write your code


if something should be true assert() it


create functions to help visualize your data


design for testing/debugging from the start


test early, test often


test at abstraction boundaries


Designing for Debug/Test

©

FPT SOFTWARE


TRAINING MATERIAL



Int
er
nal
us
e

04e
-
BM/
NS
/HDCV/FSOFT v2
/3


many bugs only happen in the uncommon case


make this case more common having switches
that cause routines to fail

-
file open, file write, memory allocation, are all good
candidates

-
Have “test drivers” which test with the
uncommon data. If deeply buried, test with a
debugger script

Fault Injection

©

FPT SOFTWARE


TRAINING MATERIAL



Int
er
nal
us
e

04e
-
BM/
NS
/HDCV/FSOFT v2
/3

Types of bugs


Types of bugs :


Compile time: syntax, spelling, static type mismatch.


Usually caught with compiler


Design: flawed algorithm.


Incorrect outputs


Program logic (if/else, loop termination, select case, etc).


Incorrect outputs


Memory nonsense: null pointers, array bounds, bad types, leaks.


Runtime exceptions


Interface errors between modules, threads, programs (in
particular, with shared resources: sockets, files, memory, etc).


Runtime Exceptions


Off
-
nominal conditions: failure of some part of software of
underlying machinery (network, etc).


Incomplete functionality


Deadlocks: multiple processes fighting for a resource.


Freeze ups, never ending processes

©

FPT SOFTWARE


TRAINING MATERIAL



Int
er
nal
us
e

04e
-
BM/
NS
/HDCV/FSOFT v2
/3

The ideal debugging process


A debugging algorithm for software engineers:


Identify test case(s) that reliably show existence of fault
(when possible)


Isolate problem to small fragment(s) of program


Correlate incorrect behavior with program logic/code error


Change the program (and check for other parts of program
where same or similar program logic may also occur)


Regression test to verify that the error has really been
removed
-

without inserting new errors


Update documentation when appropriate

(Not all these steps need be done by the same
person!)

©

FPT SOFTWARE


TRAINING MATERIAL



Int
er
nal
us
e

04e
-
BM/
NS
/HDCV/FSOFT v2
/3

General Advice


try to understand as much of what is happening
as possible


“it compiles” is
NOT

the same as “it works”


when in doubt, ask. Then test the answer!


Error messages are generally just a vague hint
and can be misleading.


Don’t always trust the “comments/documents”,
they can be out
-
of
-
date.

©

FPT SOFTWARE


TRAINING MATERIAL



Int
er
nal
us
e

04e
-
BM/
NS
/HDCV/FSOFT v2
/3

Debugging techniques, 1


Execution tracing


running the program


print


trace utilities


single stepping in debugger


hand simulation

©

FPT SOFTWARE


TRAINING MATERIAL



Int
er
nal
us
e

04e
-
BM/
NS
/HDCV/FSOFT v2
/3

Debugging techniques, 2


Interface checking


check procedure parameter number/type (if not
enforced by compiler) and value


defensive programming
: check inputs/results from
other modules


documents assumptions about caller/callee
relationships in modules, communication protocols,
etc


Assertions: include range constraints or other
information with data.


Skipping code: comment out suspect code, then
check if error remains.

©

FPT SOFTWARE


TRAINING MATERIAL



Int
er
nal
us
e

04e
-
BM/
NS
/HDCV/FSOFT v2
/3

Execution Tracing


Follows the program through the execution.
Users can step through line
-
by
-
line, or use
breakpoints.


Typically allows for “watches” on


registers,
memory locations, symbols


Allows for tracing up the stack of runtime
errors (back traces)


Allows user to trace the causes of unexpected
behavior and fix them

©

FPT SOFTWARE


TRAINING MATERIAL



Int
er
nal
us
e

04e
-
BM/
NS
/HDCV/FSOFT v2
/3

Debug vs. Release Builds


Debug builds usually are
not optimized


Debug executables contain:


program's symbol tables


location of the source file


line number tags for assembly instructions.



GCC/GDB allows debugging of optimized code.

©

FPT SOFTWARE


TRAINING MATERIAL



Int
er
nal
us
e

04e
-
BM/
NS
/HDCV/FSOFT v2
/3

Debugging Techniques


Methodology is key


Knowing about lots of debugging tools helps


The most critical tool in your arsenal is your brain


Second most important tool is a debugger


Core dumps are your friends.. Learn how to use them.


Memory debugging tools third most important


Profiler fourth

©

FPT SOFTWARE


TRAINING MATERIAL



Int
er
nal
us
e

04e
-
BM/
NS
/HDCV/FSOFT v2
/3

Avoiding bugs in the first place


Coding style: use clear, consistent style and useful
naming standards.


Document everything, from architecture and interface
specification documents to comments on code lines.


Hold code reviews.


Program defensively.


Use/implement exception handling liberally; think
constantly about anomalous conditions.


Be suspicious of cut/paste.


Consider using an integrated development environment
(IDE) with dynamic syntax checking

©

FPT SOFTWARE


TRAINING MATERIAL



Int
er
nal
us
e

04e
-
BM/
NS
/HDCV/FSOFT v2
/3

Debugging basic

Coding


The editor helps you by pointing out issues and possible resolutions.

Compiling


The compiler checks your code and reports errors before continuing

Self
-

checking


You run the application in debug mode and step through screens and code to verify
functionality.

Unit
testing


You write and run unit tests to check your application

Code
analysis


You run the Static Code Analyzer or other tools to verify that your application meets project
standards

Code review


Your code is reviewed by a peer or an architect and issues are logged accordingly.

Responding
to bug


When a bug has been logged against the code, you must recreate and debug a specific scenario



The Many Phases of Debugging

©

FPT SOFTWARE


TRAINING MATERIAL



Int
er
nal
us
e

04e
-
BM/
NS
/HDCV/FSOFT v2
/3

Debugging the Application (Self
-
Checking)

Start in debug
mode


Enable debug mode in web
config


Debug Different Processes


Break on error


Setting break point

Trace on error


Continuing the Debugging


Stepping to Find the Error

©

FPT SOFTWARE


TRAINING MATERIAL



Int
er
nal
us
e

04e
-
BM/
NS
/HDCV/FSOFT v2
/3

The visual studio debugger


VS Debugger is very complex


and ..
powerfull

©

FPT SOFTWARE


TRAINING MATERIAL



Int
er
nal
us
e

04e
-
BM/
NS
/HDCV/FSOFT v2
/3

The visual studio debugger


Windows, Breakpoints This window provides access to all the breakpoints in the option
solution.


Windows, Output. The Output window is a running log of the many messages that are emitted
by the
IDE,the

compiler, and the debugger. Therefore, the information transcends just debug
sessions.


Windows, Immediate :This window allows you to execute commands.


Start Debugging : Starts your application in debug mode.


Start Without Debugging : Starts your application without connecting the debugger to the
executing process. In this mode, the developer sees what users would see (instead of breaking
into the IDE for errors and breakpoints).


Attach to Process : Allows you to attach the debugger (and your code) to a running process
(executable). If, for example, you started the application without debugging, you could then
attach to that running process and begin debugging.


Exceptions Opens the Exceptions option dialog box. This dialog box allows you to choose how
the debugger breaks on any given exception.


Step Into & Step Over :


Toggle Breakpoint Toggles the breakpoint on or off for the current, active line of code in a text
editor. The option is inactive if you do not have a code window active in the IDE.

©

FPT SOFTWARE


TRAINING MATERIAL



Int
er
nal
us
e

04e
-
BM/
NS
/HDCV/FSOFT v2
/3

The visual studio debugger

Debugging options :

©

FPT SOFTWARE


TRAINING MATERIAL



Int
er
nal
us
e

04e
-
BM/
NS
/HDCV/FSOFT v2
/3

The visual studio debugger


Indicating When to Break into Code

©

FPT SOFTWARE


TRAINING MATERIAL



Int
er
nal
us
e

04e
-
BM/
NS
/HDCV/FSOFT v2
/3

The visual studio debugger


Setting up breakpoint condition

©

FPT SOFTWARE


TRAINING MATERIAL



Int
er
nal
us
e

04e
-
BM/
NS
/HDCV/FSOFT v2
/3

The visual studio debugger


Using a Hit Count with a Breakpoint

©

FPT SOFTWARE


TRAINING MATERIAL



Int
er
nal
us
e

04e
-
BM/
NS
/HDCV/FSOFT v2
/3

The visual studio debugger


Viewing Data in the Debugger



Watch window


Local window


Autos windows


Quick watch


Data tip

©

FPT SOFTWARE


TRAINING MATERIAL



Int
er
nal
us
e

04e
-
BM/
NS
/HDCV/FSOFT v2
/3

The visual studio debugger


Visualizing Data


Show complex object such as dataset when
debugging

©

FPT SOFTWARE


TRAINING MATERIAL



Int
er
nal
us
e

04e
-
BM/
NS
/HDCV/FSOFT v2
/3

Advanced Debugging Scenarios


Remote Debugging


Debugging WCF
Services,Web


Debugging Multithreaded Applications


Debugging a Client
-
Side Script


LINQ Debugging


©

FPT SOFTWARE


TRAINING MATERIAL



Int
er
nal
us
e

04e
-
BM/
NS
/HDCV/FSOFT v2
/3

Remote debugging


Remote debugging helps developers figure out why their
application doesn’t work in other environments.

1


Install the remote debugging monitor (msvsmon.exe) on the remote machine being debugged using
( rdbsetup.exe. )

2


Configure remote debugging permissions. Typically, this means one of two
things:You

can set up
identical accounts (username and password) on both machines (debugging and server).

3


Run the remote debugging monitor on the remote machine

4


you will have to configure your security policy and firewall for remote debugging

5


Run Visual Studio on your debug machine as you would to debug any process. Open the project
that contains the source for the process you want to debug.

6


Attach to the running process on the remote machine using Attach to Process. You will have to
browse to the machine you want to debug and find the process
runningon

that machine.

©

FPT SOFTWARE


TRAINING MATERIAL



Int
er
nal
us
e

04e
-
BM/
NS
/HDCV/FSOFT v2
/3

Debugging multithread application


Visual Studio debugger support for multi
thread application



Ability to view threads in your source during a debug
session



The Debug Location toolbar used to view processes,
threads, and flagged threads



The Thread window used to work with a list of threads in
your application



Breakpoint filters that allow you to set a breakpoint for an
individual thread

©

FPT SOFTWARE


TRAINING MATERIAL



Int
er
nal
us
e

04e
-
BM/
NS
/HDCV/FSOFT v2
/3

Debugging multithread application


Discovering and Flagging Threads


Naming threads can help you better identify them
when debugging

©

FPT SOFTWARE


TRAINING MATERIAL



Int
er
nal
us
e

04e
-
BM/
NS
/HDCV/FSOFT v2
/3

Debugging multithread application


Managing Debug Processes and Threads

©

FPT SOFTWARE


TRAINING MATERIAL



Int
er
nal
us
e

04e
-
BM/
NS
/HDCV/FSOFT v2
/3

Debugging multithread application


Breaking Based on a Specific Thread

©

FPT SOFTWARE


TRAINING MATERIAL



Int
er
nal
us
e

04e
-
BM/
NS
/HDCV/FSOFT v2
/3

Debug client side script


©

FPT SOFTWARE


TRAINING MATERIAL



Int
er
nal
us
e

04e
-
BM/
NS
/HDCV/FSOFT v2
/3

Question & Answer