<p>If you watched Fabian's <a href="https://www.youtube.com/watch?v=8bea0bdoFG0" rel="nofollow noreferrer">presentation</a> (or read the <a href="https://diyhpl.us/wiki/transcripts/scalingbitcoin/tel-aviv-2019/edgedevplusplus/debugging-bitcoin/" rel="nofollow noreferrer">transcript</a>) you'll have seen that he said you can use Valgrind for memory leak checks and that it can be used similarly to lldb.</p>
<pre><code>valgrind --leak-check=yes src/bitcoind -regtest
</code></pre>
<p>There is a section in Fabian's <a href="https://github.com/fjahr/debugging_bitcoin#valgrind" rel="nofollow noreferrer">doc</a> on debugging Bitcoin with instructions on how to install Valgrind on MacOS and run it.</p>
<p>Install Valgrind:</p>
<pre><code>brew install --HEAD https://raw.githubusercontent.com/sowson/valgrind/master/valgrind.rb
</code></pre>
<p>Run bitcoind with Valgrind:</p>
<pre><code>sudo valgrind src/bitcoind -regtest
</code></pre>
<p>Valgrind has also been added as flag to the functional tests in Core in <a href="https://github.com/bitcoin/bitcoin/pull/17633" rel="nofollow noreferrer">PR #17633</a> so you can run:</p>
<pre><code>test/functional/test_runner.py --valgrind
</code></pre>
<p>The <code>--valgrind</code> flag is documented as a Valgrind memory error detector and that you should expect at least a ~10x slowdown with Valgrind 3.14 or later required.</p>
<p>In that PR practicalswift states:</p>
<blockquote>
<p>Regular functional testing under Valgrind would have caught many of the uninitialized reads we've seen historically.</p>
</blockquote>
<p>Another great resource is a Bitcoin Core PR review club <a href="https://bitcoincore.reviews/17639" rel="nofollow noreferrer">session</a> (hosted by Jon Atack) on running the unit tests under Valgrind. In the notes for that session it describes:</p>
<blockquote>
<p>Valgrind is a debugging and profiling tool suite to make programs faster and more correct. Its most popular tool, Memcheck, can detect memory-related errors common in C and C++ programs that can lead to crashes and unpredictable behavior. Here is a <a href="https://www.cprogramming.com/debugging/valgrind.html" rel="nofollow noreferrer">tutorial</a>. Memcheck is not perfect: typical slowdown is 3-10x, memory usage is 2x, it can produce false positives (there are <a href="https://www.valgrind.org/docs/manual/manual-core.html#manual-core.suppress" rel="nofollow noreferrer">mechanisms</a> for suppressing these; see the <a href="https://github.com/bitcoin/bitcoin/blob/0.19/contrib/valgrind.supp" rel="nofollow noreferrer">valgrind.supp</a> file in Bitcoin Core), and it doesn’t currently detect out-of-range reads or writes to arrays allocated statically or on the stack.</p>
</blockquote>

CC BY-SA 4.0
2020-09-18T13:34:10.290Z
2020-09-18T13:49:22.543Z
2020-09-18T13:49:22.543Z
Michael Folkson
<p>I was watching Fabian Jahr's <a href="https://diyhpl.us/wiki/transcripts/scalingbitcoin/tel-aviv-2019/edgedevplusplus/debugging-bitcoin/" rel="nofollow noreferrer">presentation</a> on debugging Bitcoin Core at Bitcoin Edge Dev++ 2019. He mentioned Valgrind briefly at the end. What is it and when should I use it over gdb, lldb, pdb etc?</p>

<bitcoin-core-development><debugging><functional-test><bitcoincore-review><unit-test>
What is Valgrind? When should I use it for debugging Bitcoin Core over using gdb, lldb, pdb etc?
Michael Folkson
# What is Valgrind? When should I use it for debugging Bitcoin Core over using gdb, lldb, pdb etc?

(Asked by: username_0 on 2020-09-18)

I was watching Fabian Jahr's [presentation](https://diyhpl.us/wiki/transcripts/scalingbitcoin/tel-aviv-2019/edgedevplusplus/debugging-bitcoin/) on debugging Bitcoin Core at Bitcoin Edge Dev++ 2019. He mentioned Valgrind briefly at the end. What is it and when should I use it over gdb, lldb, pdb etc?

**Tags:** bitcoin-core-development, debugging, functional-test, bitcoincore-review, unit-test


---

## 1 answers

### Answer by username_0 on 2020-09-18. Score: 2 | Accepted answer

If you watched Fabian's [presentation](https://www.youtube.com/watch?v=8bea0bdoFG0) (or read the [transcript](https://diyhpl.us/wiki/transcripts/scalingbitcoin/tel-aviv-2019/edgedevplusplus/debugging-bitcoin/)) you'll have seen that he said you can use Valgrind for memory leak checks and that it can be used similarly to lldb.

```
valgrind --leak-check=yes src/bitcoind -regtest

```

There is a section in Fabian's [doc](https://github.com/fjahr/debugging_bitcoin#valgrind) on debugging Bitcoin with instructions on how to install Valgrind on MacOS and run it.

Install Valgrind:

```
brew install --HEAD https://raw.githubusercontent.com/sowson/valgrind/master/valgrind.rb

```

Run bitcoind with Valgrind:

```
sudo valgrind src/bitcoind -regtest

```

Valgrind has also been added as flag to the functional tests in Core in [PR #17633](https://github.com/bitcoin/bitcoin/pull/17633) so you can run:

```
test/functional/test_runner.py --valgrind

```

The `--valgrind` flag is documented as a Valgrind memory error detector and that you should expect at least a ~10x slowdown with Valgrind 3.14 or later required.

In that PR practicalswift states:

> Regular functional testing under Valgrind would have caught many of the uninitialized reads we've seen historically.

Another great resource is a Bitcoin Core PR review club [session](https://bitcoincore.reviews/17639) (hosted by Jon Atack) on running the unit tests under Valgrind. In the notes for that session it describes:

> Valgrind is a debugging and profiling tool suite to make programs faster and more correct. Its most popular tool, Memcheck, can detect memory-related errors common in C and C++ programs that can lead to crashes and unpredictable behavior. Here is a [tutorial](https://www.cprogramming.com/debugging/valgrind.html). Memcheck is not perfect: typical slowdown is 3-10x, memory usage is 2x, it can produce false positives (there are [mechanisms](https://www.valgrind.org/docs/manual/manual-core.html#manual-core.suppress) for suppressing these; see the [valgrind.supp](https://github.com/bitcoin/bitcoin/blob/0.19/contrib/valgrind.supp) file in Bitcoin Core), and it doesn’t currently detect out-of-range reads or writes to arrays allocated statically or on the stack.


---

