Checking NIF memory leaks with Valgrind from Elixir


does anyone have an experience for checking for a NIF memory leaks with running valgrind combined with Elixir iex -S mix session or running mix test through valgrind?

There is some information on how to build valgrind enabled OTP and run cerl with valgrind reporting enabled but I can’t find any examples of working with valgrind from Elixir side.


I had a similar issue. The OTP installation doc is quite clear. But once built, it’s not clear how to instruct elixir script to use cerl instead of erl and forward the relevant args to cerl. I ended up editing both elixir and cerl scripts as some of the options set by cerl get parsed by mix. It would be great for nif development if elixir supports cerl cc: @josevalim

Relevant section from the doc

How to Build a Debug Enabled Erlang RunTime System

After completing all the normal building steps described above a debug enabled runtime system can be built. To do this you have to change directory to $ERL_TOP/erts/emulator and execute:

$ (cd $ERL_TOP/erts/emulator && make debug)

This will produce a beam.smp.debug executable. The file are installed along side with the normal (opt) version beam.smp.

To start the debug enabled runtime system execute:

$ $ERL_TOP/bin/cerl -debug

The debug enabled runtime system features lock violation checking, assert checking and various sanity checks to help a developer ensure correctness. Some of these features can be enabled on a normal beam using appropriate configure options.

There are other types of runtime systems that can be built as well using the similar steps just described.

$ (cd $ERL_TOP/erts/emulator && make $TYPE)

where $TYPE is opt, gcov, gprof, debug, valgrind, or lcnt. These different beam types are useful for debugging and profiling purposes.


I’ve never used valgrind personally, but when writing NIFs i usually spend a lot of time in GDB.

my nif build command usually includes -g -DDEBUG in the $(CC) cflags. Once you have that you can just start your app or run your tests and use gdb with the --attach flag to attach to a pid. Might not be great for detecting a memory leak tho.

1 Like