DIR Return Create A Forum - Home
       ---------------------------------------------------------
       Class H22
  HTML https://classh22.createaforum.com
       ---------------------------------------------------------
       *****************************************************
   DIR Return to: Summeries
       *****************************************************
       #Post#: 62--------------------------------------------------
       troubleshooting
   DIR By: SpiderGoat
       Date: April 22, 2014, 9:26 am
       ---------------------------------------------------------
       When system crush – put variables to test logic bugs.
       But sometimes, it's not enough.
       For example, it could be a null pointer or a pointer filled with
       jittering.
       MMU knows everything about all pages, so it can tell if there's
       segmentation faults.
       Core dump
       process need space in memory.
       If we knew how those looked like it could have help.
       Abort create core dump.
       using shell - “ulimit -c” is maximum allowed to dump. Add
       “unlimited” so won't be '0'.
       sigsev – if write on read only. Calls abort.
       sigbus
       core dump
       nm
       objdump - for displaying various information about object files.
       file ./name
       ldd ./name 
       1. typing in shell: “ulimit -c unlimited”
       2. compile: gcc -g -Wall -Werror
       3. run: gdb  ./name ./core
       or run: gdb ./name
       then, type: core ./core
       4. run, and bt if needed
       strace – program that gives info about all functions used in
       program.
       valgrind
       valgrind --leak-check=yes myprog arg1 arg2
       The number is the process ID; it's usually unimportant.
       The first line ("Invalid write...") tells you what kind of error
       it is.
       Below the first line is a stack trace telling you where the
       problem occurred.
       Some error messages have a second component which describes the
       memory address involved.
       The stack trace tells you where the leaked memory was allocated.
       There are several kinds of leaks; the two most important
       categories are:
       "definitely lost": your program is leaking memory -- fix it!
       "probably lost": your program is leaking memory, unless you're
       doing funny things with pointers
       --track-origins=yes   should trace uninitialized pointers
       valgrind –tool=memcheck  should help with memcheck (default).
       --read-var-info=<yes|no> (default no) will read information
       about variable types and locations.
       *****************************************************
       Page 1 of 1