Apologies, the schema is quite large and there are lots of parameters in the query which I think are all mostly noise so I've not shared it. I've tried making a reduction to demonstrate / recreate the problem, but not been sucessful. The query itself is mostly in the stack dump, but I think it's unremarkable (though my assesment is fairly unqualified), though it may be relevant that I'm performing lots of inserts. So I've been trying to bisect Fossil changes to see where things start to go wrong. This has proved difficult as the crash doesn't always reliably happen. It's actually a bit strange, because if I run say the 3.35.0 release until it crashes, it will then crash _every time_ I re-attempt the same transaction. Going down through Fossil revisions will show the crash until I hit a revision which doesn't crash. And then at that point, if I go back to 3.35.0 it won't immediately crash again and I have to run for 20 minutes or longer to get it back into the 'crash every time' state so I can try a new bisection point. If I backup the sqlite files (-wal and -shm) when it is in 'crash every time' mode and restore them, it will make make the 'faulty' versions crash every time, if that makes sense. Having done this a lot, I believe this change is the culprit and the area of the change fits the area of the segfault: <a href="https://www.sqlite.org/cgi/src/info/23ca23894af352ea">https://www.sqlite.org/cgi/src/info/23ca23894af352ea</a> Specifically, sources here and later will segfault after some time and then segfault every time the transaction is retried: ```3.35.0 2021-02-23 16:40:47 23ca23894af352ea351c9efcdd7d86b82455f4c81b6001052a6d13aa2d70alt2``` Sources from here, and preceeding changes, do not segfault in these tests: ```3.35.0 2021-02-23 15:53:22 20689468100aed264877111367b42837ca19e63e717fed2ebd4b20b908f13178``` I am using PRAGMA journal_mode=WAL and PRAGMA temp_store=2, in case it is relevant.