First, a brief description of the situation: a computer sits hidden near a display in a gallery of some sort, acting as the silent workhorse for a piece.  Despite its programmer's best intentions the piece may, well, crash, from time to time depending on the passerby's interactions with the display.  The programmer has rigged up the computer to automatically restart the relevant program hackishly using a bash loop, since uptime (or something resembling it) is at a premium.The developer would love to determine what the cause of any crashes is, but running the program via GDB -- to the best of this developer's knowledge -- would result in the process stopping upon a crash.  This would indeed enable the developer to tap in 'backtrace' and find the cause, but the piece would be inoperable until the developer made his or her way to the gallery in question to check on it.  This is no good.How might this intrepid developer secure backtraces of each crash (and presumably store them somewhere) via GDB, but still allow for the original behaviour of automatically restarting the process upon a crash?
Capture and log GDB backtraces without stopping the process
linux;debugging;forensics
run ulimit -c 1073741824 prior to starting the program. Next time the program crashes, a core dump will be created in the working directory (named core.). You can then use GDB to open this core at any time you like.ulimit -c XXXXX sets the maximum size of the core dump file created when a program seg faults. By default this is '0' which means not to dump the core.