doc: add unittest core dump instructions #22226

jamesob commented at 6:03 PM on June 11, 2021: member

Quick note on how to get core dumps out of the unittests.

DrahtBot added the label Docs on Jun 11, 2021

DrahtBot added the label Tests on Jun 11, 2021

in src/test/README.md:85 in 09cea44fef outdated

  80 | +By default, the boost test runner will intercept system errors and not produce a core
  81 | +file. To bypass this, add `--catch_system_errors=no` to the `test_bitcoin` arguments
  82 | +and ensure that your ulimits are set properly (e.g. `ulimit -c unlimited`). 
  83 | +
  84 | +Running the tests and hitting a segmentation fault should now produce a file called `core`
  85 | +(depending upon your `/proc/sys/kernel/core_pattern` contents).

practicalswift commented at 6:56 PM on June 11, 2021:

Non-blocking nit: Could clarify that /proc/sys/kernel/core_pattern is Linux specific :)

jamesob commented at 7:01 PM on June 11, 2021:

Fixed, thanks

practicalswift commented at 6:56 PM on June 11, 2021: contributor

Concept ACK

jamesob force-pushed on Jun 11, 2021

theStack commented at 11:15 PM on June 11, 2021: member

Concept ACK

Possible follow-ups:

move 2nd and 3rd paragraph into more general documentation section; IMHO knowing how to find causes for crashes is useful not only for the unit-tests, but also for all other binaries that potentially segfault
~~also describe how to analyze core-dumps via lldb (if clang is used rather than gcc)~~

jamesob commented at 6:18 PM on June 12, 2021: member

describe how to analyze core-dumps via lldb (if clang is used rather than gcc)

FWIW gdb analyzes clang-built core dumps just fine for me, but maybe you meant something different.

theStack approved

theStack commented at 9:48 PM on June 12, 2021: member

describe how to analyze core-dumps via lldb (if clang is used rather than gcc)

FWIW gdb analyzes clang-built core dumps just fine for me, but maybe you meant something different.

Oh, it seems I had an ancient gdb version installed on my system, that didn't support the right DWARF version (leading me to the wrong conclusion that for clang-built core dump analysis only lldb works -- d'oh!).

ACK bbeec50921c2cfcf054ba843bda392d310de5782 📜

jamesob commented at 4:31 PM on June 21, 2021: member

Okay for merge?

in src/test/README.md:80 in bbeec50921 outdated

  73 | @@ -74,3 +74,19 @@ start debugging, just like you would with any other program:
  74 |  ```bash
  75 |  gdb src/test/test_bitcoin
  76 |  ```
  77 | +
  78 | +#### Segmentation faults
  79 | +
  80 | +By default, the boost test runner will intercept system errors and not produce a core

jonatack commented at 5:10 PM on June 21, 2021:

"Boost" is capitalized elsewhere in this file.

By default, the Boost test runner will intercept system errors and not produce a core

jonatack commented at 5:11 PM on June 21, 2021: member

Thanks for adding this. Testing the instructions.

in src/test/README.md:85 in bbeec50921 outdated

  80 | +By default, the boost test runner will intercept system errors and not produce a core
  81 | +file. To bypass this, add `--catch_system_errors=no` to the `test_bitcoin` arguments
  82 | +and ensure that your ulimits are set properly (e.g. `ulimit -c unlimited`).
  83 | +
  84 | +Running the tests and hitting a segmentation fault should now produce a file called `core`
  85 | +depending upon your `/proc/sys/kernel/core_pattern` contents (on Linux platforms).

jonatack commented at 5:41 PM on June 21, 2021:

clarify that "depending" is about the file name, not producing a file

(on Linux platforms, the file name will depend on the contents of `/proc/sys/kernel/core_pattern`).

jonatack commented at 5:41 PM on June 21, 2021: member

ACK with two suggestions (one above, one below)

MarcoFalke commented at 6:22 AM on June 22, 2021: member

review ACK bbeec50921c2cfcf054ba843bda392d310de5782

Personally I just use valgrind which will print the stack when the dump is created

jamesob commented at 5:52 PM on July 8, 2021: member

Ready for merge? Or I can add a note about valgrind?

in src/test/README.md:75 in bbeec50921 outdated

  73 | @@ -74,3 +74,19 @@ start debugging, just like you would with any other program:
  74 |  ```bash
  75 |  gdb src/test/test_bitcoin

MarcoFalke commented at 6:08 PM on July 8, 2021:

On a second thought. Won't this be enough to observe segmentation faults in gdb if they appear? Is there a reason to take the extra step of a core dump?

jamesob commented at 7:14 PM on July 19, 2021:

Yeah, this is a good point; willfix.

jamesob force-pushed on Jul 20, 2021

jamesob commented at 2:25 PM on July 20, 2021: member

Incorporated feedback from @MarcoFalke and @jonatack.

practicalswift commented at 8:26 PM on July 24, 2021: contributor

cr ACK 3ad9b71f48d2783b534264f53e059db4f239ea55

in src/test/README.md:88 in 3ad9b71f48 outdated

  83 | +
  84 | +Another tool that can be used to resolve segmentation faults is
  85 | +[valgrind](https://valgrind.org/).
  86 | +
  87 | +If for whatever reason you want to produce a core dump file for this fault, you can do
  88 | +that as well. By default, the boost test runner will intercept system errors and not

jonatack commented at 9:05 AM on July 28, 2021:

that as well. By default, the Boost test runner will intercept system errors and not

in src/test/README.md:94 in 3ad9b71f48 outdated

  89 | +produce a core file. To bypass this, add `--catch_system_errors=no` to the
  90 | +`test_bitcoin` arguments and ensure that your ulimits are set properly (e.g. `ulimit -c
  91 | +unlimited`).
  92 | +
  93 | +Running the tests and hitting a segmentation fault should now produce a file called `core`
  94 | +(on Linux platforms, the file name will likely depend on the contents of

jonatack commented at 9:05 AM on July 28, 2021:

linter appeasement

(on Linux platforms, the file name will likely depend on the contents of

in src/test/README.md:99 in 3ad9b71f48 outdated

  94 | +(on Linux platforms, the file name will likely depend on the contents of 
  95 | +`/proc/sys/kernel/core_pattern`).
  96 | +
  97 | +You can then explore the core dump using
  98 | +``` bash
  99 | +gdb src/test/test_bitcoin core

jonatack commented at 9:06 AM on July 28, 2021:

gdb ./src/test/test_bitcoin core

jonatack commented at 9:09 AM on July 28, 2021:

(you write gdb ./src/test/test_bitcoin along with bt at the top of the diff)

jonatack commented at 9:07 AM on July 28, 2021: member

This seems like a helpful improvement.

re-ACK modulo suggestions

theStack commented at 9:19 PM on July 30, 2021: member

almost re-ACK (linter is not happy yet)

Also I agree that the other suggestions by jonatack above (https://github.com/bitcoin/bitcoin/pull/22226#discussion_r678116566, #22226 (review)) should be tackled.

laanwj commented at 6:37 PM on September 16, 2021: member

LGTM, but yes it's failing the linters.

doc: test: unittest segfault gdb

Feedback from Jon Atack and Marco Falke.

12313382e6

jamesob force-pushed on Sep 16, 2021

jamesob commented at 10:24 PM on September 16, 2021: member

Fixed, thanks for the looks.

theStack approved

theStack commented at 11:47 PM on September 16, 2021: member

ACK 12313382e60c84f106127566d004c03384ca5abf

MarcoFalke referenced this in commit 6401de0133 on Sep 17, 2021

DrahtBot added the label Needs rebase on Sep 17, 2021

DrahtBot commented at 6:54 AM on September 17, 2021: member

🐙 This pull request conflicts with the target branch and needs rebase.

<sub>Want to unsubscribe from rebase notifications on this pull request? Just convert this pull request to a "draft".</sub>

fanquake commented at 6:58 AM on September 17, 2021: member

This has been merged, but wasn't closed by GitHub.

fanquake closed this on Sep 17, 2021

sidhujag referenced this in commit d0995ab3f7 on Sep 19, 2021

DrahtBot locked this on Oct 30, 2022