Using gdb to debug the chiventure tests

If a test fails because of a crash or a segmentation fault, you can use gdb to pinpoint where the crash is happening. The first thing you'll need to do is to identify the exact test that is failing. To do this, you need to run a specific test program (not the ctest program that is run by GitHub Actions). For example, if you wanted to run the Action Management tests, you would run this from inside the build/ directory (assuming you've already run cmake and make)

$ tests/action_management/test-action_management

If any of the tests fail, you will see something like this:

[----] /home/student/repos/chiventure/tests/action_management/test_item_item_actions.c:213: Unexpected signal caught below this line!
[FAIL] item_item_actions::wrong_kind_ITEM: CRASH!

The name of the test appears after [FAIL], except we'll need to replace :: with /. So the above test is actually item_item_actions/wrong_kind_ITEM. To run only that test, we need to use the --filter option, like this:

$ tests/action_management/test-action_management --filter "item_item_actions/wrong_kind_ITEM"

To actually debug the test, we need to tell Criterion that we want to run the test with GDB. Internally, Criterion will actually use the gdbserver command we described in Homework #4.

$ tests/action_management/test-action_management --filter "item_item_actions/wrong_kind_ITEM" --debug=gdb --debug-transport=tcp:1234

NOTE: If you get an error that refers to tcp:1234: cannot resolve name: Temporary failure in name resolution, you will need to run this before you run the tests:

TMP_HOSTS=$(mktemp); echo 'tcp localhost' > $TMP_HOSTS; export HOSTALIASES=$TMP_HOSTS

(you only need to run this once per terminal, not every time you want to run the test program)

If you run the tests with the --debug and --debug-transport option, the tests won't run right away and, instead, they will pause with the following message:

Listening on port 1234

NOTE: If you get an error that says Can't bind address: Address already in use., try choosing a number other than 1234 in the --debug-transport option.

Now, in a separate terminal, run gdb with the same test program. In this example, that would be the following:

$ gdb tests/action_management/test-action_management

Notice how we don't need to specify any other parameters. Once GDB starts, run the following:

target remote :1234

Followed by:

continue

The test will now run and, if it segfaults, GDB will tell you where the segfault is happening. If you're unsure of how to proceed from here, you may want to review the Micro Editor section of Homework #4.