StarUml is dead (NOT)!! Long Live the Stars!!

Star UML a very nice stable open-source design tool was suspected to be dead.
The tool is downloaded quite heavily, but development seems to have been abandoned as of 2005 with a stable release version 5.0.

But hey!! Just-a-minute, StarUML seems to have been rebooted as of (2010-July-19).
Originally written in Delphi, looks like its being converted to an eclipse plug-in in java.
Don't know how long it'll take to do the conversion though.
Seems like there are two(?) developers working on it right now.
Best of Luck to you.
Anybody with experience in Eclipse plugins and Java wanna help?!!!

Refer the project news and an announcement below:

Kick-off with Java-based StarUML Project

http://sourceforge.net/news/?group_id=152825

Delta Debugging

References:
Download Delta from delta.tigris.org
Why Programs Fail has won a Software Development Jolt Productivity Award!
Eclipse Plug-Ins - Software Engineering Chair (Prof. Zeller) - Saarland University
DDchange - DDchangeWiki
Delta Debugging article on Wikipedia
Delta Debugging articles by Andreas Zeller



See Also:
Episode 101: Podcast with Andreas Zeller on Debugging | Software Engineering Radio

Video by Andreas Zeller on Debugging the Debugging activities
Video YouTube - Learning from Code History
Mining Software Archives by Andreas Zeller
About Andreas Zeller - S/W Engg. Chair at Saarland University


Publications by Prof. Andreas Zeller

Adv Debugging - My Program Worked Yesterday, but Not Today (WYNOT) by Andreas Zellar

Brief Notes of my understanding of on Delta Debugging as discussed in “Worked Yesterday, NOt Today" by Andreas Zeller 
Note:  To understand the basic premise and constraints/approaches of Delta-Debugging referred to the pdf link to:

1. Analyse the tables/graphs carefully. (80% of the understanding comes from the example tables/graphs)
2. Connect the WYNOT talk with Andreas Zellar's podcast on Software Engineering Radio.

Problem: Yesterday's code works but Today's code doesn't. How do we find the change(s) which induces the test-case failure.
Context: Looking through the CVS history we find that N changes have been added since Yesterday.

Alternative: Normally we would need run the debugger to reproduce the failure and then try to collect information which induces it.  But this requires a programmer to interactively query the program state using a debugger.
Can the debugging be automated without needing the programmer?

Strategy: Delta Debugging using a test-case to reproduce the failure.
Data Method:
Using the Scientific Method we can first try to reduce the Input Data in a binary search mechanism to isolate the minimum data which causes the failure.
Code Method:

1. Simple Method: When failure is caused by a single change. We can try to isolate the change which causes the failure by doing a binary search through the change history. If there are N changes between Y(esterday) and T(oday) we test 'k/2'th change where 1 <= k <= N. We go on partitioning until we find a failure-free change. The latest failing change is the culprit. Complexity of this binary search is O (log N)
2. Complex Method: When failure is caused by a combination of changes. Unfortunately it's Not always possible to use the Simple Method in the case when combination of changes cause the failure. In such a situation we need to identify at least 2 (or more) changes which together cause the failure. 

• Divide the change history into N changes
• Group N changes into say 4 units i.e. N = N/4 * 4
• Generate combinations with different units.
• Test combinations for the failure. 
• Prune any units which don't participate in the failure at all.
• Recursive above steps by sub-dividing the units above (quarters into octets and so on) until we finally we end up with minimal changes that reproduce the failure.

Proposed Plans to Reduce to Reduce Computation and Avoid Inconsistent Configurations :
a) Group related changes - changes on common date/file/variable are more likely to be related. Group them into a single unit to avoid dependency across units.
b) Prune configurations when they're obvious dead-ends e.g. Where change dependency is chained all the way (Today) 10->9->8->7->6->5->4->3->2->1 (Yesterday)
c) Exclude changed code which is never executed.

See Also:
Pdf: "WYNOT - Worked Yesterday, NOt Today"
Andreas Zeller
Podcast on Software Engineering Radio
Delta Debugging

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)