A simple alternative to valgrind/memcheck that keeps track of malloc'd, calloc'd, and free'd memory and prints a diagnostic message at the end of program execution.
Find a file
2024-06-06 15:44:47 +09:00
src Check for ANOTHER_MEMCHECK_QUIET env var, refactor 2024-06-06 15:16:42 +09:00
.gitignore Add .gitignore 2024-06-04 14:54:11 +09:00
Changelog.md Check for ANOTHER_MEMCHECK_QUIET env var, refactor 2024-06-06 15:16:42 +09:00
CMakeLists.txt Check for ANOTHER_MEMCHECK_QUIET env var, refactor 2024-06-06 15:16:42 +09:00
LICENSE ADD README.md and LICENSE 2024-06-04 12:13:12 +09:00
README.md Update README.md 2024-06-06 15:44:47 +09:00

AnotherMemCheck

This software was created as an alternative to valgrind/memcheck.

How to Build

  1. Install cmake.
  2. Run cmake -S <AnotherMemCheck_project_dir> -B buildDebug.
  3. Run make -C buildDebug. The output library should be in the buildDebug/ directory.

If a release build is desired, use cmake -S <project_dir> -B buildRelease -DCMAKE_BUILD_TYPE=Release. (Note that the "build directory" was changed to "buildRelease" in the preceeding command.)

Usage

  1. Build this software with cmake.

  2. Assuming the output library is called libAnotherMemCheck.so, run your program with the LD_PRELOAD environment variable set to this library.

     LD_PRELOAD=path/libAnotherMemCheck.so ./myProgram
    
  3. When the program exits, there should be diagnostic output from this library showing all memory that has been malloced or calloced and not freeed. Note that some memory will always be shown as having been not freeed (e.g. initializing heap stuff for the program at start).

Other Notes

As mentioned earlier, there probably is memory that is always allocated at the start of a program that never gets free'd, but this should be ok because the OS should reclaim all allocated memory from a stopped process.

Also, if one wants to prevent this software from printing every malloc/calloc/free call, one can set the ANOTHER_MEMCHECK_QUIET=1 environment variable so that it only prints unfree'd memory at program execution end.

Since this is relatively newly written software (as of middle of 2024), there might be a memory leak within this software when keeping track of memory. Thus, this software may be revised later on. If you are interested in verifying whether there is a memory leak or not, you may check the source and submit an issue/pull-request if there is any discovered issue with the software.