A debugger or debugging tool is a computer program that is used to test and debug other programs

(the "target" program). The code to be examined might alternatively be running on an instruction set
simulator (ISS), a technique that allows great power in its ability to halt when specific conditions are
encountered but which will typically be somewhat slower than executing the code directly on the
appropriate (or the same) processor. Some debuggers offer two modes of operation - full or partial
simulation, to limit this impact.
A "crash" happens when the program cannot normally continue because of a programming bug. For
example, the program might have tried to use an instruction not available on the current version of the
CPU or attempted to access unavailable or protected memory. When the program "crashes" or reaches a
preset condition, the debugger typically shows the position in the original code if it is a source-level
debugger or symbolic debugger, commonly now seen in integrated development environments. If it is
a low-level debugger or a machine-language debugger it shows the line in the disassembly (unless it
also has online access to the original source code and can display the appropriate section of code from
the assembly or compilation).

The importance of a good debugger cannot be overstated. Indeed, the existence and quality of such a
tool for a given language and platform can often be the deciding factor in its use, even if another
language/platform is better-suited to the task.[citation needed]. The absence of a debugger, having once
been accustomed to using one, has been said to "make you feel like a blind man in a dark room looking
for a black cat that isn’t there".[1] However, software can (and often does) behave differently running
under a debugger than normally, due to the inevitable changes the presence of a debugger will make to
a software program's internal timing. As a result, even with a good debugging tool, it is often very
difficult to track down runtime problems in complex multi-threaded or distributed systems.

Most current mainstream debugging engines, such as gdb and dbx provide console-based command
line interfaces. Debugger front-ends are popular extensions to debugger engines that provide IDE
integration, program animation, and visualization features. Some early mainframe debuggers such as
IBM OLIVER (CICS interactive test/debug) and SIMON (Batch Interactive test/debug) provided this
same functionality for the IBM System/360 and later operating systems, as long ago as the 1970s.

What is Valgrind?
•a multipurpose code profiling and memory debugging
tool
• monitors memory usage such as calls to malloc and
free (or
new and delete in C++)
• Valgrinds detects:
• usage of uninitialized memory
• write off the end of an array
• if you forget to free a pointer
• Other tools
•
Addrcheck
, similar to Memcheck but with much smaller CPU and
memory overhead.
•
Massif
, a heap profiler
•
Helgrind
and
DRD
, detect race conditions in multithreaded code
•
Cachegrind
, a cache profiler (GUI KCacheGrind)
•
Callgrind
, a callgraph analyzer (GUI KCacheGrind)
Systems Architecture Group
http://sar.informatik.hu-berlin.de

Valgrind
Usage
• valgrind –tool=
valgrind_tool program_name
• tools:
• memcheck
• callgrind
• cachegrind
• Example
% valgrind --tool=memcheck program_name
...
=18515== malloc/free: in use at exit: 0 bytes in 0
blocks.
==18515== malloc/free: 1 allocs, 1 frees, 10 bytes
allocated.
==18515== For a detailed leak analysis, rerun with:
--leak-check=yes
Valgrind is compiled into a Linux shared object, valgrind.so, and also a dummy one,
valgrinq.so, of which more later. The valgrind shell script adds valgrind.so to the
LD_PRELOAD list of extra libraries to be loaded with any dynamically linked library. This is a standard
trick, one which I assume the LD_PRELOAD mechanism was developed to support.

valgrind.so is linked with the -z initfirst flag, which requests that its initialisation code is
run before that of any other object in the executable image. When this happens, valgrind gains control.
The real CPU becomes "trapped" in valgrind.so and the translations it generates. The synthetic
CPU provided by Valgrind does, however, return from this initialisation function. So the normal startup
actions, orchestrated by the dynamic linker ld.so, continue as usual, except on the synthetic CPU, not
the real one. Eventually main is run and returns, and then the finalisation code of the shared objects is
run, presumably in inverse order to which they were initialised. Remember, this is still all happening on
the simulated CPU. Eventually valgrind.so's own finalisation code is called. It spots this event,
shuts down the simulated CPU, prints any error summaries and/or does leak detection, and returns from
the initialisation code on the real CPU. At this point, in effect the real and synthetic CPUs have merged
back into one, Valgrind has lost control of the program, and the program finally exit()s back to the
kernel in the usual way.

Valgrind is a GPL'd system for debugging and profiling Linux programs. With Valgrind's tool suite you
can automatically detect many memory management and threading bugs, avoiding hours of frustrating
bug-hunting, making your programs more stable. You can also perform detailed profiling to help speed
up your programs.

Valgrind is a suite that provides several tools for debugging and profiling Linux programs. Although it
works with programs written in many different languages -- such as Java, Perl, Python, Assembly
code, Fortran, Ada and more -- the tools it provides are largely aimed at programs written in C and C+
+.Nov 20, 2015

When the web browser loads a web page, the HTML parser begins parsing the HTML code and
creating the DOM. Whenever the parser encounters a CSS or JavaScript directive (inline or externally
loaded), it gets handed over to the CSS parser or the JavaScript engine as required. The JavaScript
engine loads external JavaScript files and inline code, but does not run the code immediately. It waits
for the HTML and CSS parsing to complete. Once this is done, the JavaScript is executed in the order
they were found on the web page: variables and functions are defined, function invocations are
executed, event handlers are triggered, etc. These activities result in the DOM being updated by the
JavaScript and is rendered instantly by the browser.