Re: [Swarm-Support] crash at odd timestep

[Marcus G. Daniels]

Paul Johnson wrote:
> Paul Box is right that gdb might lead to the line in your code where 
> the crash is triggered
For anyone that has spent days trying to find the cause of crash or 
failure, or has had the stack corrupted such that gdb has no useful 
backtrace, here are some developments that may be of interest.

- VMware Workstation 6.0 now has a record/playback capability.   It 
actually records the instructions executed to a file so that they can be 
replayed with the help of gdb.  

http://blogs.vmware.com/sherrod/2007/04/the_amazing_vm_.html

There's some talk of patches to the popular QEMU simulator to do the 
same thing (page 69):

http://ols.108.redhat.com/2007/GCC-Reprints/GCC2007-Proceedings.pdf

- Chronicle is a wrapper around the valgrind simulator.   Essentially 
this simulates your code and compresses the instruction stream to a 
file, which can then be queried.   An Eclipse plugin called Chronomancer 
provides a debugging interface to Chronicle.

http://code.google.com/p/chronomancer/

- There's a set of patches to GDB and the SID simulation framework to 
give gdb a "back" as well as "next" feature.

http://sourceware.org/ml/sid/2006-q3/msg00047.html
http://sourceware.org/ml/gdb-patches/2006-03/msg00388.html
http://sourceware.org/ml/gdb-patches/2006-03/msg00389.html
http://sourceware.org/ml/gdb-patches/2006-03/msg00390.html

The use this, the idea would be to set up a cross compiler for xstormy16 
(one of the many GCC backends), and then run your model in that 
simulator.   When a crash occurs, you simply back up to GDB and travel 
backward in time!

Reversible debugging has been around for awhile, but it's been 
commercial and expensive, often involving special purpose hardware.  
Looks like it's finally coming to the mainstream..

Marcus