Valgrind Support Level

Valgrind is a memory mis-management detector. It shows you memory leaks, deallocation errors, mismanaged threads, rogue reads/writes, etc. CINELERRA-GG memory management is designed to work with Valgrind detection methods. This assists in developing reliable code. Use of Valgrind points out problems so that they can be fixed. For example, when this version of CINELERRA-GG shuts down, it deallocates memory instead of just stopping, thus making memory leak detection possible. An alternative to Valgrind is heaptrack which has good documentation and for large programs can run faster. You can find the source and information about it at https://github.com/KDE/heaptrack.

The best way to compile and run valgrind is to run the developer static build. This takes 2 steps and you must already have gdb and valgrind installed:

1. The standard static build:
   cd /path/cinelerra-5.1
   make clean
   ./bld.sh
2. run the incremental rebuild for debug objs:
   CFLAGS=-ggdb make -j8 rebuild_all

If you frequently make mods and changes in CINELERRA-GG or the thirdparty libraries, do not depend on those compiled versions to have the headers updated; so be sure to fully rebuild as shown in the previous 2 steps before running valgrind or you will get false errors.

Now your CINELERRA-GG obj has all of the debug stuff. Next run valgrind as root for the most useful results:

cd /path/cinelerra-5.1/cinelerra

valgrind --log-file=/tmp/log --leak-check=full
--num-callers=32 ./ci

This runs CINELERRA-GG under the control of valgrind, and produces a log file in /tmp which will list information about any leaks, usually clearly identifiable. Be sure to Quit out of CINELERRA-GG normally instead of Ctrl-C or a SEGV otherwise the program does not have a chance to cleanup and there will be some false alarms. But it runs very slowly, and is basically single threaded, which means that race conditions may be impossible to catch... like one thread deletes memory that another thread is currently using. But overall it is a big help and if you test any new features, please email the log output. A lot of effort when writing the code was put into trying to be sure that all of the object constructors have matching destructors so that the leaks can be identified. There are already several libraries that create predictable memory leaks and valgrind does a good job for most of these.

It is impossible to test everything with valgrind because some things are just too big and slow for a practical test. Occasionally you can find a leak or an illegal memory access. There are several false alarms that are difficult to avoid Conditional jump messages, and unhandled DW_OP_, but anything with the word illegal in the message is important. Memory leaks that originate in CINELERRA-GG are good to find and fix, but are usually not deadly. The listing of the memory leaks can be quite voluminous so locating the LEAK SUMMARY section towards the end of the report is most useful.

Another very useful valgrind run to locate unitialized variables while executing is:

valgrind --log-file=/tmp/log --tool=memcheck
--num-callers=32 ./ci