Oh. I didn't get a notification about your reply (I've just double-checked my inbox, trash bin and spam folders), so I missed it... and therefore, I missed the fact that this issue doesn't contain the tarball I had created before posting !
The most likely reason is probably that I forgot to upload it, though I seldom do that, but I'm going to stealthily pretend that the upload failed or that a pro-virus deleted the file - hopefully nobody notices my poor attempt at covering up :)

Sorry, anyhow :(

(file #403)

Like most code bases, gdbm unwittingly uses undefined behaviour, as evidenced by e.g. building the project with AFL++ afl-clang-fast with AFL_USE_UBSAN=1 environment variable and fuzzing gdbmtool with afl-fuzz.
For debugging the issues, building with gcc or clang -fsanitize=undefined should do the job, no need to involve AFL++ or Honggfuzz :)

The set of commands is the same as some of my recent bug reports:
avail
cache
count
dir
header
current
first
next
status
recover
reorganize
fetch 1
delete 1
store 1 1
delete 1
bucket 1
quit

Fixing every kind of reported usage of undefined behaviour might arguably be lower priority than fixing memory errors reported by ASAN and MSAN instrumentation, hence the Normal severity.
I used a fuzzer instance running the MSAN-instrumented binary and an instance running the UBSAN-instrumented binary concurrently and cooperatively; MSAN instrumentation didn't find any UMRs in 6+h and 200+K execs, which is partially good news: at least the UMRs aren't easy to find, but the coverage is still very insufficient.