DragonX/hush3
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Add some useful tips about gdb and testcoins to dev notes

Browse Source
This commit is contained in:
Duke
2024-01-25 08:56:47 -08:00
parent 04b122a067
commit 1612ca4da7
1 changed files with 34 additions and 7 deletions
Download Patch File Download Diff File Expand all files Collapse all files

41
doc/developer-notes.md
View File

@@ -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**