DOCSLIB.ORG

Post Mortem Crash Analysis

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
Post Mortem Crash Analysis Post Mortem Crash Analysis Johan Heander & Magnus Malmborn January 14, 2007 Abstract To improve the quality and reliability of embedded systems it is important to gather information about errors in units already sold and deployed. To achieve this, a system for transmitting error information from the customer back to the developers is needed, and the developers must also have a set of tools to analyze the error reports. The purpose of this master thesis was to develop a fully functioning demon- stration system for collection, transmission and interpretation of error reports from Axis network cameras using the Linux operating system. The system has been shown to handle both kernel and application errors and conducts automatic analysis of received data. It also uses standard HTTP protocol for all network transfers making it easy to use even on firewalled net- works. i ii Acknowledgement We would like to thank our LTH supervisor Jonas Skeppstedt for all he has taught us about computer science in general and operating systems and the C programming language in particular. We would also like to thank Mikael Starvik at Axis Communications for quickly providing us with all hardware and information we needed to complete this thesis, and for providing us with support during our implementation and writing. Finally we thank all the developers working at Axis Communications, many of whom have provided input and reflections on our work. iii iv Contents 1 Introduction 1 1.1 Problem description . 1 1.2 Problem analysis . 1 2 Background 3 2.1 Kernel crashes . 3 2.2 User space crashes . 5 2.2.1 Core dump generation under Linux . 5 2.3 Existingproducts........................... 6 2.3.1 netdump . 7 2.4 Other systems . 7 2.4.1 Windows XP . 7 2.4.2 MacOS X . 7 2.4.3 Solaris 10 . 8 3 System 9 3.1 Target platform . 9 3.2 Desired information . 9 3.3 User space errors . 9 3.4 Core dump compression . 10 3.4.1 Run length encoding . 11 3.4.2 LZMA . 12 3.5 The netcore file system . 12 3.6 Kernel errors . 13 3.6.1 Extending the kernel Oops . 13 3.7 Core dump analysis . 14 3.7.1 Linux core files . 14 3.7.2 Call trace and the CRIS architecture . 15 3.7.3 The coreinfo tool . 15 3.8 Fingerprinting . 16 3.8.1 Core dump fingerprinting . 16 3.8.2 Recursion errors . 18 3.8.3 Oops fingerprinting . 22 3.9 Customer server . 22 3.10 Axis server . 22 v 4 Validation 25 4.1 Validation of crash reports . 25 4.1.1 User space crashes . 25 4.1.2 Kernel crashes . 25 4.2 Compression . 26 5 Conclusion 29 5.1 Discussion . 29 5.1.1 Signal handlers . 29 5.1.2 Patents . 29 5.2 Further improvements . 30 6 Summary 31 A Dictionary 33 Bibliography 33 vi Chapter 1 Introduction To improve long term reliability of embedded systems it is important to follow up and analyze faults in deployed units. This can be difficult, since a deployed system generally is and should be inaccessible to the developers; thus it is nec- essary to allow the customer to report errors as they occur, at her discretion. Since software crashes are unfortunately fairly common, it is easy to be over- loaded with debug information unless there is a system in place to automate the analysis. The target products for this thesis are network cameras from Axis Commu- nications. These cameras are embedded devices with limited hardware resources running a standard Linux kernel and a number of applications handling video processing and user interaction. Definitions of terms used in this thesis can be found in appendix A on page 33. 1.1 Problem description This thesis project have derived: • Means to save debug information from the cameras when a kernel or ap- plication error occurs and propagating it back to Axis. • Tools for automated analysis of collected debug information. The thesis have also developed a prototype system demonstrating these steps, running on real camera hardware. 1.2 Problem analysis The problem led to the following specific sub-tasks: • Investigation of what kind of debug information the developers want from a crashed system, and if any additional useful information can be extracted at a low additional cost. • Development of a reliable fingerprinting algorithm to recognize multiple reports of the same error. 1 1.2. PROBLEM ANALYSIS CHAPTER 1. INTRODUCTION • Creation of a system for transferring debug information from the camera back to Axis. • Development of an aggregation scheme for grouping and ranking error reports. The prototype system consists of four different parts. One part running on the camera to detect crashes, extract error information and transfer the error information to the customer. Somewhere on the customer’s network there is software that receives error reports from the cameras and presents them to the user, so that she can authorize the sending of information to Axis. At Axis there is server software to receive error reports from all the customers, as well as various tools that can be used by the Axis developers to further analyze the reports. The general structure is shown in figure 1.1. Figure 1.1: System network architecture The prototype system demonstrates functional implementations of all four parts. The most work has been put into the parts running on the camera and the tools for report analysis. These parts should be reliable and ready to use in production systems. The servers at the customer and at Axis needs to be integrated in the existing software infrastructure in order to be suitable for production systems, and no attempts have been made to develop this kind of integration. The goal was only to develop a fully functional demonstration system. The software parts running on the camera should not use the processor at all under normal system operation, and incur no extra overhead on normal program execution. During crashes, processor usage should be kept as low as possible to ensure fast error handling. Memory usage should be kept very low during both normal operation and crashes to avoid disturbing the video software. On the customer server, disk space usage should be kept low but it can be assumed to have abundant processor and memory resources. The Axis crash report server is dedicated to handling crash reports and have plenty of disk space, memory and processor resources, as well as access to source code and binary debugging information. 2 Chapter 2 Background Software errors can be of many different types[12], e.g.: logic errors The program is valid, but does something other than was in- tended, e.g. printing the wrong range of pages. deadlocks The system hangs when two or more parts stop to wait for each other. The situation is akin to two people meeting in a doorway; each need to wait for the other to move out of the way, and—since neither computers nor people back up voluntarily—neither can move because the other is blocking the way. illegal memory references A program tries to access memory it is not al- lowed to, and gets terminated by the operating system. memory corruption A program accidentally writes to the wrong place in memory, destroying the previous data. Later when the previous data is needed, the newly written data is read back instead, causing unpredictable errors. Some of these errors are detected automatically, e.g. illegal memory references, since they are so obviously illegal that the computer cannot execute them, but other errors are more a question of whether the program behaves as the user expects it to or not. In these cases only the user can decide when an error has occurred. The handling of illegal software operations differs significantly if it is the operating system kernel itself that raises the error or an ordinary user space process. During user space crashes the rest of the system is usually fully func- tional and can be used to process the crash data. Kernel crashes are more complicated since no part of the system can be trusted to be in a consistent state. 2.1 Kernel crashes Under Linux, if an error is detected while running in kernel mode the kernel outputs a short plain-text report, called a kernel Oops, containing a short de- scription of the error together with a dump of register values, the top of the 3 2.1. KERNEL CRASHES CHAPTER 2. BACKGROUND stack, a short call trace and the bytes around the current value of the program counter, see example in figure 2.1. Most other operating systems behave in a similar way, but the message is called something else. Under Linux the kernel Oops is printed using the general kernel debug printing function printk(). As can be seen the format is fairly compact; the size of a kernel Oops is generally below 2 KiB1 but can, in the worst case, grow to about 20 KiB for recursion errors. Oops: 0002 Modules linked in: oopsmod2[d0074000+788] artpec_2[d0094000+26544] CPU: 0 ERP: d0074006 SRP: c001db88 CCS: 40028008 USP: 00000000 MOF: 00000140 r0: d00745f0 r1: c31dd200 r2: 400000a8 r3: c31dd208 r4: ffffe000 r5: d00745ec r6: 00000000 r7: d0074000 r8: 00000003 r9: 4000002a r10: 00000000 r11: d00745f4 r12: c31dd210 r13: c31dd208 oR10: 00000000 acr: 00000000 sp: c07ddf0c Data MMU Cause: 000002a5 Instruction MMU Cause: d00740a5 Process oopsmod2queue/0 (pid: 1281, stackpage=c04a8780) Stack from c07ddf6c: c31dd208 00000001 c31dd200 c0020ae2 c001dbee fffffffc c00075b6 00000000 00000000 c001dcfc c00209f8 c05f9f30 c000ba62 c31dd200 ffffffff ffffffff 00000001 00000000 c000b902 00010000 00000000 00000000 c04a8780 c000b902 Call Trace: [<c0020ae2>] [<c001dbee>] [<c00075b6>] [<c001dcfc>] [<c00209f8>] [<c000ba62>] [<c000b902>] [<c000b902>] Code: -- -- -- -- -- -- 7f 86 4f 9e 2a 00 (cf) 9b 7f 9d 14 06 00 00 a9 0b 20 20 Figure 2.1: Typical kernel Oops Analyzing a kernel Oops is the simplest form of kernel debugging, but some tools are available that instead of saving just the kernel Oops saves a complete dump of the system memory.
Load more

Recommended publications
  • Introduction to Debugging the Freebsd Kernel
    Introduction to Debugging the FreeBSD Kernel John H. Baldwin Yahoo!, Inc. Atlanta, GA 30327 [email protected], http://people.FreeBSD.org/˜jhb Abstract used either directly by the user or indirectly via other tools such as kgdb [3]. Just like every other piece of software, the The Kernel Debugging chapter of the FreeBSD kernel has bugs. Debugging a ker- FreeBSD Developer’s Handbook [4] covers nel is a bit different from debugging a user- several details already such as entering DDB, land program as there is nothing underneath configuring a system to save kernel crash the kernel to provide debugging facilities such dumps, and invoking kgdb on a crash dump. as ptrace() or procfs. This paper will give a This paper will not cover these topics. In- brief overview of some of the tools available stead, it will demonstrate some ways to use for investigating bugs in the FreeBSD kernel. FreeBSD’s kernel debugging tools to investi- It will cover the in-kernel debugger DDB and gate bugs. the external debugger kgdb which is used to perform post-mortem analysis on kernel crash dumps. 2 Kernel Crash Messages 1 Introduction The first debugging service the FreeBSD kernel provides is the messages the kernel prints on the console when the kernel crashes. When a userland application encounters a When the kernel encounters an invalid condi- bug the operating system provides services for tion (such as an assertion failure or a memory investigating the bug. For example, a kernel protection violation) it halts execution of the may save a copy of the a process’ memory current thread and enters a “panic” state also image on disk as a core dump.
    [Show full text]
  • Process and Memory Management Commands
    Process and Memory Management Commands This chapter describes the Cisco IOS XR software commands used to manage processes and memory. For more information about using the process and memory management commands to perform troubleshooting tasks, see Cisco ASR 9000 Series Aggregation Services Router Getting Started Guide. • clear context, on page 2 • dumpcore, on page 3 • exception coresize, on page 6 • exception filepath, on page 8 • exception pakmem, on page 12 • exception sparse, on page 14 • exception sprsize, on page 16 • follow, on page 18 • monitor threads, on page 25 • process, on page 29 • process core, on page 32 • process mandatory, on page 34 • show context, on page 36 • show dll, on page 39 • show exception, on page 42 • show memory, on page 44 • show memory compare, on page 47 • show memory heap, on page 50 • show processes, on page 54 Process and Memory Management Commands 1 Process and Memory Management Commands clear context clear context To clear core dump context information, use the clear context command in the appropriate mode. clear context location {node-id | all} Syntax Description location{node-id | all} (Optional) Clears core dump context information for a specified node. The node-id argument is expressed in the rack/slot/module notation. Use the all keyword to indicate all nodes. Command Default No default behavior or values Command Modes Administration EXEC EXEC mode Command History Release Modification Release 3.7.2 This command was introduced. Release 3.9.0 No modification. Usage Guidelines To use this command, you must be in a user group associated with a task group that includes appropriate task IDs.
    [Show full text]
  • Linux Core Dumps
    Linux Core Dumps Kevin Grigorenko [email protected] Many Interactions with Core Dumps systemd-coredump abrtd Process Crashes Ack! 4GB File! Most Interactions with Core Dumps Poof! Process Crashes systemd-coredump Nobody abrtd Looks core kdump not Poof! Kernel configured Crashes So what? ● Crashes are problems! – May be symptoms of security vulnerabilities – May be application bugs ● Data corruption ● Memory leaks – A hard crash kills outstanding work – Without automatic process restarts, crashes lead to service unavailability ● With restarts, a hacker may continue trying. ● We shouldn't be scared of core dumps. – When a dog poops inside the house, we don't just `rm -f $poo` or let it pile up, we try to figure out why or how to avoid it again. What is a core dump? ● It's just a file that contains virtual memory contents, register values, and other meta-data. – User land core dump: Represents state of a particular process (e.g. from crash) – Kernel core dump: Represents state of the kernel (e.g. from panic) and process data ● ELF-formatted file (like a program) User Land User Land Crash core Process 1 Process N Kernel Panic vmcore What is Virtual Memory? ● Virtual Memory is an abstraction over physical memory (RAM/swap) – Simplifies programming – User land: process isolation – Kernel/processor translate virtual address references to physical memory locations 64-bit Process Virtual 8GB RAM Address Space (16EB) (Example) 0 0 16 8 EB GB How much virtual memory is used? ● Use `ps` or similar tools to query user process virtual memory usage (in KB): – $ ps -o pid,vsz,rss -p 14062 PID VSZ RSS 14062 44648 42508 Process 1 Virtual 8GB RAM Memory Usage (VSZ) (Example) 0 0 Resident Page 1 Resident Page 2 16 8 EB GB Process 2 How much virtual memory is used? ● Virtual memory is broken up into virtual memory areas (VMAs), the sum of which equal VSZ and may be printed with: – $ cat /proc/${PID}/smaps 00400000-0040b000 r-xp 00000000 fd:02 22151273 /bin/cat Size: 44 kB Rss: 20 kB Pss: 12 kB..
    [Show full text]
  • The Complete Freebsd
    The Complete FreeBSD® If you find errors in this book, please report them to Greg Lehey <grog@Free- BSD.org> for inclusion in the errata list. The Complete FreeBSD® Fourth Edition Tenth anniversary version, 24 February 2006 Greg Lehey The Complete FreeBSD® by Greg Lehey <[email protected]> Copyright © 1996, 1997, 1999, 2002, 2003, 2006 by Greg Lehey. This book is licensed under the Creative Commons “Attribution-NonCommercial-ShareAlike 2.5” license. The full text is located at http://creativecommons.org/licenses/by-nc-sa/2.5/legalcode. You are free: • to copy, distribute, display, and perform the work • to make derivative works under the following conditions: • Attribution. You must attribute the work in the manner specified by the author or licensor. • Noncommercial. You may not use this work for commercial purposes. This clause is modified from the original by the provision: You may use this book for commercial purposes if you pay me the sum of USD 20 per copy printed (whether sold or not). You must also agree to allow inspection of printing records and other material necessary to confirm the royalty sums. The purpose of this clause is to make it attractive to negotiate sensible royalties before printing. • Share Alike. If you alter, transform, or build upon this work, you may distribute the resulting work only under a license identical to this one. • For any reuse or distribution, you must make clear to others the license terms of this work. • Any of these conditions can be waived if you get permission from the copyright holder. Your fair use and other rights are in no way affected by the above.
    [Show full text]
  • Exniffer: Learning to Rank Crashes by Assessing the Exploitability from Memory Dump
    Exniffer: Learning to Rank Crashes by Assessing the Exploitability from Memory Dump Thesis submitted in partial fulfillment of the requirements for the degree of MS in Computer Science & Engineering by Research by Shubham Tripathi 201407646 [email protected] International Institute of Information Technology Hyderabad - 500 032, INDIA March 2018 Copyright c Shubham Tripathi, March 2018 All Rights Reserved International Institute of Information Technology Hyderabad, India CERTIFICATE It is certified that the work contained in this thesis, titled “Exniffer: Learning to Rank Crashes by Assessing the Exploitability from Memory Dump” by Shubham Tripathi, has been carried out under my supervision and is not submitted elsewhere for a degree. Date Adviser: Prof. Sanjay Rawat “Contemplate and reflect upon knowledge, and you will become a benefactor to others.” To my parents Acknowledgments I would like to express my gratitude to my adviser, Dr. Sanjay Rawat. Sanjay sir helped me staying focused on problems and provided new directions to approach them. Working with him, I have devel- oped my problem solving skills, learnt about research, about life in general. I would be thankful to him for all my life, for providing me the guidance on various matters, always motivating and boosting me with confidence, which really helped me in shaping my life. I must also thank all my lab-mates who are working or have worked earlier in CSTAR - Vijayendra, Spandan, Satwik, Charu, Teja, Ishan and Lokesh. I really enjoyed working with them in the lab. I would like to thank all my friends in IIIT, for making my stay in the campus a memorable one.
    [Show full text]
  • Chapter 2: Operating-System Structures
    Chapter 2: Operating-System Structures Operating System Concepts – 10th Edition Silberschatz, Galvin and Gagne ©2018 Chapter 2: Operating-System Structures Operating System Services User and Operating System-Interface System Calls System Services Linkers and Loaders Why Applications are Operating System Specific Operating-System Design and Implementation Operating System Structure Building and Booting an Operating System Operating System Debugging Operating System Concepts – 10th Edition 2.2 Silberschatz, Galvin and Gagne ©2018 Objectives Identify services provided by an operating system Illustrate how system calls are used to provide operating system services Compare and contrast monolithic, layered, microkernel, modular, and hybrid strategies for designing operating systems Illustrate the process for booting an operating system Apply tools for monitoring operating system performance Design and implement kernel modules for interacting with a Linux kernel Operating System Concepts – 10th Edition 2.3 Silberschatz, Galvin and Gagne ©2018 Operating System Services Operating systems provide an environment for execution of programs and services to programs and users One set of operating-system services provides functions that are helpful to the user: User interface - Almost all operating systems have a user interface (UI). Varies between Command-Line (CLI), Graphics User Interface (GUI), touch-screen, Batch Program execution - The system must be able to load a program into memory and to run that program, end execution, either normally or abnormally (indicating error) I/O operations - A running program may require I/O, which may involve a file or an I/O device Operating System Concepts – 10th Edition 2.4 Silberschatz, Galvin and Gagne ©2018 Operating System Services (Cont.) One set of operating-system services provides functions that are helpful to the user (Cont.): File-system manipulation - The file system is of particular interest.
    [Show full text]
  • Comparing the Robustness of POSIX Operating Systems
    Comparing the Robustness of POSIX Operating Systems http://www.ices.cmu.edu/ballista Philip Koopman & John DeVale ECE Department [email protected] - (412) 268-5225 - http://www.ices.cmu.edu/koopman ,QVWLWXWH IRU &RPSOH[ (QJLQHHUHG 6\VWHPV Overview: Ballista Automated Robustness Testing ◆ Generic robustness testing • Based on data types ◆ OS Testing results • Raw results for 15 Operating Systems • System calls vs. C Library ◆ Exception Handling Diversity • Does everyone core dump on the same exceptions? (no) ◆ Approximating “Silent” failure rates (missing error codes) A Ballista is an ancient siege ◆ Conclusions/Future work weapon for hurling objects at fortified defenses. 2 Ballista: Software Testing + Fault Injection Ideas ◆ SW Testing requires: Ballista uses: • Test case “Bad” value combinations • Module under test Module under Test • Oracle (a “specification”) Watchdog timer/core dumps SPECIFIED INPUT RESPONSE BEHAVIOR SPACE SPACE ROBUST SHOULD VAL I D OPERATION WORK INPUTS MO DULE REPRODUCIBLE UNDEFINED UNDER FAILURE TEST SHOULD INVALID INPUTS UNREPRODUCIBLE RETURN FAILURE ERROR ◆ Ballista combines ideas from: • Domain testing ideas / Syntax testing ideas • Fault injection at the API level 3 Scalable Test Generation API write(int filedes, const void *buffer, size_t nbytes) FILE MEMORY SIZE TESTING DESCRIPTOR BUFFER TEST OBJECTS TEST OBJECT TEST OBJECT OBJECT FD_CLOSED BUF_SMALL_1 SIZE_1 FD_OPEN_READ BUF_MED_PAGESIZE SIZE_16 FD_OPEN_WRITE BUF_LARGE_512MB SIZE_PAGE FD_DELETED BUF_XLARGE_1GB SIZE_PAGEx16 FD_NOEXIST BUF_HUGE_2GB SIZE_PAGEx16plus1
    [Show full text]
  • Chapter 2 Operating System Structures
    Operating Systems Associate Prof. Yongkun Li 中科大-计算机学院 副教授 http://staff.ustc.edu.cn/~ykli Chapter 2 Operating System Structures 1 Objectives • Operating System Services – User Operating System Interface – System Calls • Operating System Structure • Operating System Design and Implementation • MISC: Debugging, Generation & System Boot 2 Operating System Services Services Overview, User Interface 3 Operating System Services • Operating systems provide – an environment for execution of programs and – services to programs and users • Services may differ from one OS to another • What are the common classes? – Convenience of the user – Efficiency of the system 4 Overview of Operating System Services 5 OS Services for Helping Users • User interface - Almost all operating systems have a user interface (UI). – Three forms • Command-Line (CLI) – Shell command • Batch – Shell script • Graphics User Interface (GUI) – Windows system 6 OS Services for Helping Users • Program execution – Load a program into memory – Run the program – End execution • either normally or • abnormally (indicating error) 7 OS Services for Helping Users • I/O operations - A running program may require I/O, which may involve a file or an I/O device – Common I/Os: read, write, etc. – Special functions: recording CD/DVD • Notes: Users usually cannot control I/O devices directly, so OS provides a mean to do I/O – Mainly for efficiency and protection 8 OS Services for Helping Users • File-system manipulation - The file system is of particular interest – OS provides a variety of file systems • Major services – read and write files and directories – create and delete files and directories – search for a given file – list file Information – permission management: allow/deny access 9 OS Services for Helping Users • Communications: information exchange between processes – Processes on the same computer – Processes between computers over a network • Implementations – Shared memory • Two or more processes read/write to a shared section of mem.
    [Show full text]
  • Troubleshooting Typical Issues in Oracle Solaris 11.1
    TroubleshootingTypical Issues in Oracle® Solaris 11.1 Part No: E29013–01 October 2012 Copyright © 1998, 2012, Oracle and/or its affiliates. All rights reserved. This software and related documentation are provided under a license agreement containing restrictions on use and disclosure and are protected by intellectual property laws. Except as expressly permitted in your license agreement or allowed by law, you may not use, copy, reproduce, translate, broadcast, modify, license, transmit, distribute, exhibit, perform, publish, or display any part, in any form, or by any means. Reverse engineering, disassembly, or decompilation of this software, unless required by law for interoperability, is prohibited. The information contained herein is subject to change without notice and is not warranted to be error-free. If you find any errors, please report them to us in writing. If this is software or related documentation that is delivered to the U.S. Government or anyone licensing it on behalf of the U.S. Government, the following notice is applicable: U.S. GOVERNMENT END USERS. Oracle programs, including any operating system, integrated software, any programs installed on the hardware, and/or documentation, delivered to U.S. Government end users are "commercial computer software" pursuant to the applicable Federal Acquisition Regulation and agency-specific supplemental regulations. As such, use, duplication, disclosure, modification, and adaptation of the programs, including anyoperating system, integrated software, any programs installed on the hardware, and/or documentation, shall be subject to license terms and license restrictions applicable to the programs. No other rights are granted to the U.S. Government. This software or hardware is developed for general use in a variety of information management applications.
    [Show full text]
  • Development of Tool for Data De-Serialization of Memory Dumps (Octeon & TI DSP Multicore Environment)
    Volume : 4 | Issue : 5 | May 2015 ISSN - 2250-1991 Research Paper Engineering Development of Tool for Data De-Serialization of Memory Dumps (Octeon & TI DSP Multicore Environment) Digital Communication Engineering, RV College of Engineering, *Sumukha Prasad U Bengaluru, India. *Corresponding Author Giri Prasad Nokia Networks, R&D Technology Centre, Bengaluru, India. Digital Communication Engineering, RV College of Engineering, RK Manjunath Bengaluru, India. In the Digital Era, the Wireless Mobile Networks are more predominant which are wide spread in all the applications and the robust designs are being prepared for it, the end-user has noticed and there is a need for faster, accurate and much more capable versions of Base Station Controllers to uphold the highly dense cellular traffic. The best methodologies are being usage of high speed multi-core processors and using multi-threading concepts. Although the chip accuracy and speed have boosted to a greater extent, multi-core processing remains as the favorite concept for all the electronic manufacturers including the mobile handset makers. Over the years, even though adding of multiple cores to the DSPs, full benefit & efficiency of the technology is not exploited. This paper deals with the cause for the hindrance that is causing the multi-core processors from giving its fullest thrust in its functionality. The main reason is due to unavailability of its register contents ABSTRACT during the crash of a processor. The BSC2000 uses multicore Octeon & Texas Instruments DSP in its ETP interface cards; henceforth this paper provides a methodology to retrieve the register contents from processor’s crash binary contents. A standalone tool is developed to provide the contents in the readable format and displayed according to the processor contents.
    [Show full text]
  • Freebsd System Programming Freebsd System Programming
    FreeBSD system programming FreeBSD system programming Authors: Nathan Boeger (nboeger at khmere.com) Mana Tominaga (manna at dumaexplorer.com ) Copyright (C) 2001,2002,2003,2004 Nathan Boeger and Mana Tominaga Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.1 or any later version published by the Free Software Foundation; with no Invariant Sections, one Front-Cover Texts, and one Back-Cover Text: "Nathan Boeger and Mana Tominaga wrote this book and asks for your support through donation. Contact the authors for more information" A copy of the license is included in the section entitled GNU Free Documentation License" Welcome to the FreeBSD System Programming book. Please note that this is a work in progress and feedback is appreciated! please note a few things first: • We have written the book in a new format. I have read many programming books that have covered many different areas. Personally, I found it hard to follow code with no comments or switching back and forth between text explaining code and the code. So in this book, after chapter 1, I have split the code and text into separate pieces. The source code for each chapter is online and fully downloaded able. That way if you only want to check out the source code examples you can view them only. And if you want to understand the concepts you can read the text or even have them side by side. Please let us know your thoughts on this • The book was ordinally intended to be published in hard copy form.
    [Show full text]
  • Analysis and Visualization of Linux Core Dumps
    Submitted by Dominik Steinbinder Submitted at Institute for System Software Supervisor Prof. Hanspeter M¨ossenb¨ock Co-Supervisor Dr. Philipp Lengauer 03 2018 Analysis and Visualization of Linux Core Dumps Master Thesis to obtain the academic degree of Diplom-Ingenieur in the Master's Program Computer Science JOHANNES KEPLER UNIVERSITY LINZ Altenbergerstraße 69 4040 Linz, Osterreich¨ www.jku.at DVR 0093696 Abstract This thesis deals with an automated approach to analyzing Linux core dumps. Core dumps are binary files that contain the runtime memory of a process running in a Linux based operating system. The dump analysis tool extracts and visualizes relevant information from core dumps. More advanced users can start a manual debugging session from within the web interface and thereby access all functions that a conventional debugger supports. By integrating the tool into a third party issue tracking system, core dumps are fetched and analyzed automatically. Therefore, the analysis is started as soon as a core dump is uploaded into the issue tracking system. The tool also keeps track of analysis results. The collected data can be filtered and visualized in order to provide a statistical evaluation but also to detect anomalies in the crash history. Zusammenfassung Diese Arbeit befasst sich mit der automatischen Analyse von Linux Core Dumps. Core Dumps sind bin¨are Dateien, die das Speicherabbild eines Prozesses im Betriebssystem Linux enthalten. Das Analyse Tool extrahiert und visualisiert relevante Information aus Core Dumps. Fortgeschrittene Benutzer k¨onnen uber¨ das Web Interface eine manuelle Debugging Session starten und s¨amtliche Befehle eines konventionellen Debuggers be- nutzen. Durch die Integration in ein Issue-Tracking-System kann das Tool selbst¨andig Core Dumps finden.
    [Show full text]