Crash Dumps for Analysis

If you get a SEGV crash and can explain what steps you took, a /tmp/cinelerra_<pid> .dmp file is very useful for analysis. You can also use Ctrl-c in the controlling window to force an INTR signal interrupt when you think the program is hung up. You can only perform one Ctrl-c as the second Ctrl-c quits out of the program. It is best to upload the .dmp, input files and other files to datafilehost or similar temporary site as they may be quite large. The .dmp filename looks like /tmp/cinelerra_<pid> .dmp Log a bug report or email all helpful information on the crash, location of uploaded files, and list of setup steps that illustrate the problem to [email protected]

1. Use the latest version of CINELERRA-GG as you want to make sure the problem has not been fixed.
2. Be sure gdb is installed (usually installed but if not, it is easy to do so).
3. Run as root if at all possible (this enables using gdb to create a full /tmp/cinelerra* .dmp file).
4. Be sure Settings → Preferences → Interface → trap SEGV and trap INTR are checked.
5. Invoke the error. This should create the file /tmp/cinelerra-<pid>.dmp

For those who can not run as root or can not create the problem while running as root, another method to create a dump is available. Here are the steps to do so – you should also have gdb installed.

1. Temporarily login as root and key in:
   echo 0 > /proc/sys/kernel/yama/ptrace_scope
   This opens up ptrace, used by gdb (the debugger). You will want to reverse this when done.
2. Run CINELERRA-GG as an ordinary user from a window using the command line and try to create the problem. If the program crashes, this should produce a file named /tmp/cinelerra*.dmp where * is a number. The dump usually takes about 30 seconds or so to complete after the failure invokes the crash handler, so be patient.
3. Email the output that shows in the window from where you started up CINELERRA-GG and upload or directly email the /tmp/cinelerra*.dmp file (this file may be too large for the Mailing List).
4. After you are finished creating/testing the problem, reverse the previous setting while logged in as root by keying in:
   echo 1 > /proc/sys/kernel/yama/ptrace_scope

Even if you are not logged in as root or have ptrace enabled, if you have a .dmp file and know what the last thing you did is, please provide the .dmp file for analysis. There is a low probability that the dump will prove useful, but if the problem can be recreated it can usually be fixed!