Debugging with GDB's Cheat-Sheet of Commonly Used Options

Gdb:
Compiling a program for debugging:
    g++ -ggdb -O0 hello.cpp   # 
    g++ -g3 -O0 hello.cpp       # -g3 compiles debugging info for preprocessor macros and no optimization

Running a program under the debugger without arguments
$> gdb myProgram

Setting the program arguments:
   a)  $> gdb --args myProgram  10 20 30 40
   b)  (gdb) start 10 20 30 40  # sets temporary breakpoint at main() and calls run.
   c)  (gdb) file myProgram
        (gdb) run 10 20 30 40
   d)   (gdb)  set args 10 20 30 40
         (gdb) show args
        (gdb) run
    e) $> gdb myProgram core
    f) $> gdb -tui myProgram core  # start vim/emacs ide for debug session

Howto Debug a Core-Dump/Crash-Dump for a stripped binary from a production machine

Core dump Analysis:
core(5)– (Linux Programmer's Manual – File Formats)
Core Dump (Wikipedia)
Memory dump (Wikipedia)
CallStack (Wikipedia),
Enabling core dumps in embedded systems,


Dr Dobbs - Postmortem Debugging
Dr Dobbs - Post-Mortem Debugging Revisited

Stackoverflow article (with comments) on core dump analysis on Solaris,
Backtrace commands in GDB documentation
Howto generate a Backtrace for Bug Reporting by Testers (from Gentoo doc)

Stack buffer overflow (Wikipedia)

Segmentation fault (SIG_SEGV, SIG_BUS)
A FAQ: User contributed answers regarding the definition of a segmentation fault,
A "null pointer" explained,
Answer to: NULL is guaranteed to be 0, but the null pointer is not?
Resolving crashes and segmentation faults,
What is the difference between a segmentation fault and a stack overflow?

Windows:
Crash dump analysis website


Books:
Debugging: The Nine Indispensable Rules for Finding Even the Most Elusive Software and Hardware Problems (by David J. Agans)
Software Exorcism: A Handbook for Debugging and Optimizing Legacy Code (by Bill Blunden)
Debugging by Thinking : A Multidisciplinary Approach (by Robert C. Metzger)
Memory Dump Analysis Anthology, Volume 1  (by Dmitry Vostokov)

Steps towards Technical Mastery

How do you know if you've become a Master in your field?

Is there any method to learn things quickly in any field?
How do you avoid stagnation and mediocrity after becoming competent in your field?
How do you become a Master?

Take software for example: How do you become a Master in it?

These are exactly the questions which have been pushing me to seek answers.
Well now that I've got some kind of grip on this quest I'm able to give some of the answers.
Or at the very least point the way.

Short Answer: You'll know it when you get there!!
Long Answer: You'll see the Sign-Posts as you move towards achieving Mastery. Read on for the gory details.

Basic Template with Ingredients for a Technical Blog

A good Technical Blog Post follows the Law Of Retention: repetition helps Retention

Some Questions on your Blog Post:

• Is your blog a frequently used resource for yourself and your readers? 
• Does it grow as you learn more - addressing different levels of questions?
• Is it short and informative while being complete and self-contained? 

Is your blog addressing The Readers Perspective?

1. What's in it for a Reader?
2. Tell 'em what you're going to Tell 'em.
3. Tell 'em.
   
4. Tell 'em what you just told 'em.
   
5. Further info.

Understand Source Code by Reading Code and Refactoring for Maintaining Large Projects

This list consists of one-liner tips to be used for easy lookup and reference.

Rewriting Code for Better Understanding (Coding Horror)

• What I cannot create, I do not understand. [Richard Feynman]
• "What I do not create, I do not understand."[Chris]
• "It's easier to understand 600 tables than 100,000 lines of code." [PaulC on comp.databases.theory/2005]
• Create a new project with blocks of code copied from old code. Refactor to reduce "old code smell"
• Start refactoring by adding small tests to better understand code and act as regression tests.
• Just scan through huge amounts of code till it starts making sense - "understand by constant exposure".
• Create a text file to capture your understanding - briefly describe how the component works, realtions to other components, what it persists, its states, and source browsing/debugging tips you found useful.
• Manually reformat a copy of the code - white space, and indented as per your personal style.

References:

1. Working Effectively with Legacy Code
2. Object Oriented Reengineering Patterns
3. Refactoring: Improving the Design of Existing Code