From 1612ca4da7249f70ba79c10f609a46909a23097a Mon Sep 17 00:00:00 2001 From: Duke Date: Thu, 25 Jan 2024 08:56:47 -0800 Subject: [PATCH] Add some useful tips about gdb and testcoins to dev notes --- doc/developer-notes.md | 41 ++++++++++++++++++++++++++++++++++------- 1 file changed, 34 insertions(+), 7 deletions(-) diff --git a/doc/developer-notes.md b/doc/developer-notes.md index d8027f38e..a2d90a7d3 100644 --- a/doc/developer-notes.md +++ b/doc/developer-notes.md @@ -24,6 +24,34 @@ rm zindex.dat blocks chainstate database notarizations hushstate It's possible to confused hush if you ran old code, stop, restart, and then write out zindex.dat that is incorrect, which later hushds will load from disk and believe. +# Generating a backtrace from a coredump + +Sometimes the code coredumps, what are ya gonna do? Generate a backtrace, of course. + +Run `ulimit -c unlimited` to make sure your shell will generate coredumps and +then run the application which coredumps. In the Olden Times Linux would always +make the "core" file in the same dir as the binary that was run which created +it. But I have now seen that some new Linux distributions put them in weird +places, for instance Arch puts them in /var/lib/systemd/coredump . If there are +lots of coredumps and you don't know which one is the latest, sort them by +modification time `ls -lart` or just delete them all and run the code which +generates the core dump. Old coredumps are not very useful and take up lots of space. + +Once you have a coredump file (which is usually called "core" or "core.XYZ" +where XYZ is the PID that generated it) you can then type `gdb binary_name +core_filename` and then type bt to generate the backtrace. + +For this repo, it's likely this is the command you need: +``` +gdb src/hushd core +``` + +NOTE: Even if you are debugging a coredump on a HAC, such as DragonX, the file `src/dragonxd` +is just a shell script that calls `src/hushd` and you always want to give an actual executable +file as the first argument to `gdb`, not a bash script. + +This link about Advanced GDB is very useful: https://interrupt.memfault.com/blog/advanced-gdb + # Parsing RPC output with jq jq is a very useful tool to parse JSON output, install it with: @@ -182,15 +210,14 @@ error and debugging messages are written there. The -debug=... command-line option controls debugging; running with just -debug or -debug=1 will turn on all categories (and give you a very large debug.log file). -**testnet and regtest modes** +**test coins** -Run with the -testnet option to run with "play HUSH" on the test network, if you -are testing multi-machine code that needs to operate across the internet. You can -also make a Hush Smart Chain "testcoin" with a single command: `hushd -ac_name=COIN ...` +The main way to test new things is directly on mainnet or you can also make a +Hush Arrakis Chain "testcoin" with a single command: `hushd -ac_name=COIN ...` -If you are testing something that can run on one machine, run with the -regtest option. -In regression test mode, blocks can be created on-demand; see qa/rpc-tests/ for tests -that run in -regtest mode. +If you are testing something that can run on one machine you can use `-testnode=1` +which makes it so a single machine can create a new blockchain and mine blocks, i.e. +no peers are necessary. **DEBUG_LOCKORDER**