I can't reproduce on OpenBSD 7.1-current or 6.9-release with neither a
debug nor release build of trunk.

Can you run a backtrace on the core file?

No core dump is produced, this is a call to fossil_panic() or whatever and that doesn't do that AFAIU. Did you compile with -static?

Both with ./configure --static and without. I've no idea why I can't
reproduce it. But I now see Richard's fix.

I just looked at the code, Richard's installed a segv handler, that's
why there's no core file. Though it looks like it provides a backtrace
on some platforms.

Yeah, on GNU systems it will do a nicer backtrace. OpenBSD lacks backtrace(3), I think some of the other BSDs might have it -- one can get around it by using libexecinfo on OpenBSD if one wants. That might be a nice thing to do to the configure script, check if the library exists, and define HAVE_BACKTRACE ...

I discovered that recently when looking to install a segv handler in
fnc. When I realised I couldn't show the trace on base OpenBSD, I
scrapped the idea. The BUGS section in 6.9's backtrace(3) is funny
but I can't bring it up on https://man.openbsd.org for some reason.

That's a good idea about tweaking the configure script though.

ETA: copypasta from my local manpage

BUGS
     As typical with GNU software the interface is clumsy and error prone.
     While writing a more sophisticated backtracing mechanism it was obvious
     that the GNU functionality could be trivially emulated.

     Due to a bug in gcc one has to compile applications with the following
     flags -Wl,--export-dynamic in order to get human readable function names.

Please try again with the latest trunk check-in.

That does the trick, thank you!

Thank you for handling the issue while I was away!
I'm sorry for the bother; I did not expect that g.zPath may be NULL.

@ams, thank you for reporting that issue.

Any tips on debugging?

The first thing to try, assuming you're working from a checkout which has been used to build multiple versions, is "make clean" and then reconfigure and rebuild. Once in a blue moon dependencies don't quite work and we end up linking an old/binary-incompatible object file in there somewhere. It doesn't happen often, but when it does it often results in weirdness like inexplicable segfaults.

Edit: nevermind - Richard's concurrent response seems like the more likely culprit.

I found the problem by running:

valgrind ./fossil server /home/drh/www/repos --repolist

Valgrind told me the exact source code line where the problem was occurring. From there, the fix was easy.