mirror of
https://github.com/dashpay/dash.git
synced 2024-12-25 03:52:49 +01:00
merge bitcoin#22226: add unittest core dump instructions
This commit is contained in:
parent
a83f76b0d5
commit
c4fe6085c8
@ -74,3 +74,29 @@ start debugging, just like you would with any other program:
|
|||||||
```bash
|
```bash
|
||||||
gdb src/test/test_dash
|
gdb src/test/test_dash
|
||||||
```
|
```
|
||||||
|
|
||||||
|
#### Segmentation faults
|
||||||
|
|
||||||
|
If you hit a segmentation fault during a test run, you can diagnose where the fault
|
||||||
|
is happening by running `gdb ./src/test/test_dash` and then using the `bt` command
|
||||||
|
within gdb.
|
||||||
|
|
||||||
|
Another tool that can be used to resolve segmentation faults is
|
||||||
|
[valgrind](https://valgrind.org/).
|
||||||
|
|
||||||
|
If for whatever reason you want to produce a core dump file for this fault, you can do
|
||||||
|
that as well. By default, the boost test runner will intercept system errors and not
|
||||||
|
produce a core file. To bypass this, add `--catch_system_errors=no` to the
|
||||||
|
`test_dash` arguments and ensure that your ulimits are set properly (e.g. `ulimit -c
|
||||||
|
unlimited`).
|
||||||
|
|
||||||
|
Running the tests and hitting a segmentation fault should now produce a file called `core`
|
||||||
|
(on Linux platforms, the file name will likely depend on the contents of
|
||||||
|
`/proc/sys/kernel/core_pattern`).
|
||||||
|
|
||||||
|
You can then explore the core dump using
|
||||||
|
``` bash
|
||||||
|
gdb src/test/test_dash core
|
||||||
|
|
||||||
|
(gbd) bt # produce a backtrace for where a segfault occurred
|
||||||
|
```
|
||||||
|
Loading…
Reference in New Issue
Block a user