Debugging

From Things and Stuff Wiki
Revision as of 04:27, 8 February 2019 by Milk (talk | contribs)
Jump to navigation Jump to search


General

See *nix#System calls, Development#Testing




  • https://en.wikipedia.org/wiki/Debug_symbol - a special kind of symbol that attaches additional information to the symbol table of an object file, such as a shared library or an executable. This information allows a symbolic debugger to gain access to information from the source code of the binary, such as the names of identifiers, including variables and routines. The symbolic information may be compiled together with the module's binary file, or distributed in a separate file, or simply discarded during the compilation and/or linking. This information can be helpful while trying to investigate and fix a crashing application or any other fault.


  • Debugging Information in Separate Files - GDB allows you to put a program’s debugging information in a file separate from the executable itself, in a way that allows GDB to find and load the debugging information automatically. Since debugging information can be very large—sometimes larger than the executable code itself—some systems distribute debugging information for their executables in separate files, which users can install only when they need to debug a problem.


  • https://en.wikipedia.org/wiki/Dynamic_program_analysis - the analysis of computer software that is performed by executing programs on a real or virtual processor. For dynamic program analysis to be effective, the target program must be executed with sufficient test inputs to produce interesting behavior. Use of software testing measures such as code coverage helps ensure that an adequate slice of the program's set of possible behaviors has been observed. Also, care must be taken to minimize the effect that instrumentation has on the execution (including temporal properties) of the target program. Dynamic analysis is in contrast to static program analysis. Unit tests, integration tests, system tests and acceptance tests use dynamic testing.


Instrumentation

  • https://en.wikipedia.org/wiki/Instrumentation_(computer_programming) - refers to an ability to monitor or measure the level of a product's performance, to diagnose errors, and to write trace information. Programmers implement instrumentation in the form of code instructions that monitor specific components in a system (for example, instructions may output logging information to appear on the screen). When an application contains instrumentation code, it can be managed by using a management tool. Instrumentation is necessary to review the performance of the application. Instrumentation approaches can be of two types: source instrumentation and binary instrumentation.





printk


  • https://en.wikipedia.org/wiki/Printk printk - a function that prints messages and is used in the C Programming Language exclusively for the Linux Kernel. It accepts a string parameter called the format string, which specifies a method for rendering an arbitrary number of varied data type parameter(s) into a string. The string is then printed to the kernel log.It provides a printf-like abstraction and its parsing of the format string and arguments behave exactly the same way. It acts as a debugging tool for kernel programmers who need this function for logging messages from the kernel.



KProbes / dprobes




  • https://en.wikipedia.org/wiki/Dprobes - a Linux kernel analysis framework created in 2004, which features the ability to insert software probes dynamically into running code. It is based on kprobes.


Kernel_marker

  • https://en.wikipedia.org/wiki/Kernel_marker - were a static kernel instrumentation support mechanism for Linux kernel source code, allowing special tools such as LTTng or SystemTap to trace information exposed by these probe points. A patch-set implementing them was merged into version 2.6.24, which was released on January 24, 2008. To address issues regarding kernel markers, Mathieu Desnoyers, their original author, implemented a simpler and more type-safe version of static probe points named Tracepoints.


ptrace

  • https://en.wikipedia.org/wiki/Ptrace - system call found in several Unix and Unix-like operating systems. By using ptrace (the name is an abbreviation of "process trace") one process can control another, enabling the controller to inspect and manipulate the internal state of its target. ptrace is used by debuggers and other code-analysis tools, mostly as aids to software development.


ftrace

  • Ftrace - an internal tracer designed to help out developers and designers of systems to find what is going on inside the kernel. It can be used for debugging or analyzing latencies and performance issues that take place outside of user-space. Although ftrace is typically considered the function tracer, it is really a frame work of several assorted tracing utilities. There's latency tracing to examine what occurs between interrupts disabled and enabled, as well as for preemption and from a time a task is woken to the task is actually scheduled in.




truss

  • https://en.wikipedia.org/wiki/truss_(Unix) - system tool available on some Unix-like operating systems. When invoked with an additional executable command-line argument, truss makes it possible to print out the system calls made by and the signals received by this executable command-line argument. As of version IEEE Std 1003.1-2008, truss is not part of the Single UNIX Specification (POSIX). The truss command was originally developed by Roger Faulkner and Ron Gomes as part of the development of Procfs for System V Release 4. While several names were considered, “truss” was chosen for being non-ambiguous and easily pronounceable, with multiple meanings, including as an abbreviation for TRace Unix Syscalls and Signals or in the sense of “If your program doesn’t work, put it in a truss.”


strace

ltrace


DTrace

  • https://en.wikipedia.org/wiki/DTrace - a comprehensive dynamic tracing framework created by Sun Microsystems for troubleshooting kernel and application problems on production systems in real time. Originally developed for Solaris, it has since been released under the free Common Development and Distribution License (CDDL) and has been ported to several other Unix-like systems. In December 2012, Oracle announced the general availability of DTrace for Oracle Linux.



ktrace

  • https://en.wikipedia.org/wiki/ktrace - a utility included with certain versions of BSD Unix and Mac OS X that traces kernel interaction with a program and dumps it to disk for the purposes of debugging and analysis. Traced kernel operations include system calls, namei translations, signal processing, and I/O. ktrace is somewhat similar to Linux's strace, except for being much faster – with strace, every system call executed by the traced program requires context switch to the tracing program and back, while the tracing with ktrace is actually performed by the kernel, so no additional context switches are required.


LTT / LTTng

  • https://en.wikipedia.org/wiki/Linux_Trace_Toolkit - a set of tools that is designed to log program execution details from a patched Linux kernel and then perform various analyses on them, using console-based and graphical tools. LTT has been mostly superseded by its successor LTTng (Linux Trace Toolkit Next Generation).
trace 15 foo
  # trace for 15 seconds

traceview foo
  # view results


  • LTTng - an open source tracing framework for Linux.

SystemTap

  • SystemTap - provides free software (GPL) infrastructure to simplify the gathering of information about the running Linux system. This assists diagnosis of a performance or functional problem. SystemTap eliminates the need for the developer to go through the tedious and disruptive instrument, recompile, install, and reboot sequence that may be otherwise required to collect data. SystemTap provides a simple command line interface and scripting language for writing instrumentation for a live running kernel plus user-space applications. We are publishing samples, as well as enlarging the internal "tapset" script library to aid reuse and abstraction. Among other tracing/probing tools, SystemTap is the tool of choice for complex tasks that may require live analysis, programmable on-line response, and whole-system symbolic access. SystemTap can also handle simple tracing jobs.



eBPF


BCC

  • BCC - a toolkit for creating efficient kernel tracing and manipulation programs, and includes several useful tools and examples. It makes use of eBPF (Extended Berkeley Packet Filters), a new feature that was first added to Linux 3.15. Much of what BCC uses requires Linux 4.1 and above. [6]

bpftrace



Crashes


  • https://en.wikipedia.org/wiki/Core_dump - crash dump, memory dump, or system dump consists of the recorded state of the working memory of a computer program at a specific time, generally when the program has crashed or otherwise terminated abnormally. In practice, other key pieces of program state are usually dumped at the same time, including the processor registers, which may include the program counter and stack pointer, memory management information, and other processor and operating system flags and information. A snapshot dump (or snap dump) is a memory dump requested by the computer operator or by the running program, after which the program is able to continue. Core dumps are often used to assist in diagnosing and debugging errors in computer programs.


kdump

  • https://en.wikipedia.org/wiki/kdump_(Linux) - a feature of the Linux kernel that creates crash dumps in the event of a kernel crash. When triggered, kdump exports a memory image (also known as vmcore) that can be analyzed for the purposes of debugging and determining the cause of a crash. The dumped image of main memory, exported as an Executable and Linkable Format (ELF) object, can be accessed either directly through /proc/vmcore during the handling of a kernel crash, or it can be automatically saved to a locally accessible file system, to a raw device, or to a remote system accessible over network.

Apport

  • https://wiki.ubuntu.com/Apport - a system which: intercepts crashes right when they happen the first time, gathers potentially useful information about the crash and the OS environment, can be automatically invoked for unhandled exceptions in other programming languages (e. g. in Ubuntu this is done for Python), can be automatically invoked for other problems that can be automatically detected (e. g. Ubuntu automatically detects and reports package installation/upgrade failures from update-manager), presents a UI that informs the user about the crash and instructs them on how to proceed, and is able to file non-crash bug reports about software, so that developers still get information about package versions, OS version etc.


Debugging

gdb






Valgrind

  • Valgrind - an instrumentation framework for building dynamic analysis tools. There are Valgrind tools that can automatically detect many memory management and threading bugs, and profile your programs in detail. You can also use Valgrind to build new tools.
    • https://en.wikipedia.org/wiki/Valgrind - a programming tool for memory debugging, memory leak detection, and profiling. Valgrind was originally designed to be a free memory debugging tool for Linux on x86, but has since evolved to become a generic framework for creating dynamic analysis tools such as checkers and profilers.



  • Callgrind / KCachegrind - profiling tool and the profile data visualization Both are licensed under GPL V2. Callgrind uses runtime instrumentation via the Valgrind framework for its cache simulation and call-graph generation. This way, even shared libraries and dynamically opened plugins can be profiled. The data files generated by Callgrind can be loaded into KCachegrind for browsing the performance results. But there is also a command line tool in the package to get ASCII reports from data files without the need to use KCachegrind. The format of Callgrind output is documented here. With conversion scripts, KCachegrind is able to visualize output of other profilers like OProfile, a system-wide profiler for Linux using statistical sampling with hardware performance counters. There also exist converters for profiling output of Python, PHP and PERL.

rr

  • rr - aspires to be your primary C/C++ debugging tool for Linux, replacing — well, enhancing — gdb. You record a failure once, then debug the recording, deterministically, as many times as you want. The same execution is replayed every time. rr also provides efficient reverse execution under gdb. Set breakpoints and data watchpoints and quickly reverse-execute to where they were hit.


QIRA


radare2

  • radare - started as a forensics tool, a scriptable commandline hexadecimal editor able to open disk files, but later support for analyzing binaries, disassembling code, debugging programs, attaching to remote gdb servers, .. r2 is a rewrite from scratch of radare in order to provide a set of libraries and tools to work with binary files.


voltron

  • https://github.com/snare/voltron - an extensible debugger UI toolkit written in Python. It aims to improve the user experience of various debuggers (LLDB, GDB, VDB and WinDbg) by enabling the attachment of utility views that can retrieve and display data from the debugger host. By running these views in other TTYs, you can build a customised debugger user interface to suit your needs. [10]


ProcDump-for-Linux

  • https://github.com/Microsoft/ProcDump-for-Linux - a Linux reimagining of the classic ProcDump tool from the Sysinternals suite of tools for Windows. ProcDump provides a convenient way for Linux developers to create core dumps of their application based on performance triggers. [11]


coala

  • coala - provides a unified interface for linting and fixing code with a single configuration file, regardless of the programming languages used. You can use coala from within your favorite editor, integrate it with your CI, get the results as JSON, or customize it to your needs with its flexible configuration syntax. [12]



Senseye

  • https://github.com/letoram/senseye - Dynamic Visual Debugging / Reverse Engineering Toolsuite. a set of data providers, parsers that work with the Arcan display servers IPC subsystem, and as a set of extension script for the Durden desktop environment/window management scheme.


to sort



  • Flame - graphs are a visualization of profiled software, allowing the most frequent code-paths to be identified quickly and accurately. They can be generated using my open source programs on github.com/brendangregg/FlameGraph, which create interactive SVGs. See the Updates section for other implementations.


  • jtool - a command meant to meet and exceed the functionality to XCode's otool(1), picking up along the way additional Mach-O commands such as atos(1), dyldinfo(1), nm(1), segedit(1), pagestuff(1), strings(1), and even codesign(1) and the informal ldid. jtool also provides novel features, such in-binary search functionality, symbol injection and a disassembler functionality with (limited but constantly improving) emulation capabilities. It also provides color output. Most importantly, it can be run on a variety of platforms - OS X, iOS, and even Linux. It is ENTIRELY FREE for use of any type, and the latest version




  • Forkstat - a program that logs process fork(), exec() and exit() activity. It is useful for monitoring system behaviour and to track down rogue processes that are spawning off processes and potentially abusing the system.











  • Dwarf Home - a debugging file format used by many compilers and debuggers to support source level debugging. It addresses the requirements of a number of procedural languages, such as C, C++, and Fortran, and is designed to be extensible to other languages. DWARF is architecture independent and applicable to any processor or operating system. It is widely used on Unix, Linux and other operating systems, as well as in stand-alone environments.
Retrieved from "https://wiki.thingsandstuff.org/index.php?title=Debugging&oldid=49599"