During repair, it's normal to encounter a partially-written tree, which can contain arbitrary invalid data. We can't crash when that happens; we need to gracefully fail so the repair can try the other commit slot instead.
This first batch of fixes only covers the crashes most likely to occur in practice: the ones that can happen on a 64-bit machine, without malicious input. There are several more arithmetic overflows that can only happen on 32-bit machines, which are simple to fix but I haven't done yet (I can probably look at these after #878). There are also a number of trickier crashes that can only happen when there's corrupt data with a valid checksum, which is unlikely to happen accidentally but definitely possible with malicious input. #878 will greatly improve the situation there.
If it's useful, I have .redb files which will reproduce most of these crashes; if you'd like them, just let me know.
During repair, it's normal to encounter a partially-written tree, which can contain arbitrary invalid data. We can't crash when that happens; we need to gracefully fail so the repair can try the other commit slot instead.
This first batch of fixes only covers the crashes most likely to occur in practice: the ones that can happen on a 64-bit machine, without malicious input. There are several more arithmetic overflows that can only happen on 32-bit machines, which are simple to fix but I haven't done yet (I can probably look at these after #878). There are also a number of trickier crashes that can only happen when there's corrupt data with a valid checksum, which is unlikely to happen accidentally but definitely possible with malicious input. #878 will greatly improve the situation there.
If it's useful, I have .redb files which will reproduce most of these crashes; if you'd like them, just let me know.