Skip to main content
added 22 characters in body
Source Link
Michael Folkson
  • 15.8k
  • 3
  • 21
  • 58

If you watched Fabian's presentation (or read the transcript) 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 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 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 on Valgrind is a Bitcoin Core PR review club session (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. Memcheck is not perfect: typical slowdown is 3-10x, memory usage is 2x, it can produce false positives (there are mechanisms for suppressing these; see the 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.

If you watched Fabian's presentation (or read the transcript) 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 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 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 on Valgrind is a Bitcoin Core PR review club session (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. Memcheck is not perfect: typical slowdown is 3-10x, memory usage is 2x, it can produce false positives (there are mechanisms for suppressing these; see the 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.

If you watched Fabian's presentation (or read the transcript) 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 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 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 (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. Memcheck is not perfect: typical slowdown is 3-10x, memory usage is 2x, it can produce false positives (there are mechanisms for suppressing these; see the 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.

added 22 characters in body
Source Link
Michael Folkson
  • 15.8k
  • 3
  • 21
  • 58

If you watched Fabian's presentation (or read the transcript) 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 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 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.

But circling back to your initial questionIn that PR practicalswift states:

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

Another great resource on when to use Valgrind if debugging Bitcoin Core. The best resource I could find is a Bitcoin Core PR review club session (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. Memcheck is not perfect: typical slowdown is 3-10x, memory usage is 2x, it can produce false positives (there are mechanisms for suppressing these; see the 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.

If you watched Fabian's presentation (or read the transcript) 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 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 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.

But circling back to your initial question on when to use Valgrind if debugging Bitcoin Core. The best resource I could find is a Bitcoin Core PR review club session 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. Memcheck is not perfect: typical slowdown is 3-10x, memory usage is 2x, it can produce false positives (there are mechanisms for suppressing these; see the 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.

If you watched Fabian's presentation (or read the transcript) 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 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 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 on Valgrind is a Bitcoin Core PR review club session (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. Memcheck is not perfect: typical slowdown is 3-10x, memory usage is 2x, it can produce false positives (there are mechanisms for suppressing these; see the 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.

Source Link
Michael Folkson
  • 15.8k
  • 3
  • 21
  • 58

If you watched Fabian's presentation (or read the transcript) 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 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 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.

But circling back to your initial question on when to use Valgrind if debugging Bitcoin Core. The best resource I could find is a Bitcoin Core PR review club session 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. Memcheck is not perfect: typical slowdown is 3-10x, memory usage is 2x, it can produce false positives (there are mechanisms for suppressing these; see the 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.