I queried Eric off-list about LB's design goals in respect of risk for
segfault.

Eric clarified that LB is intended to never cause a segfault, however,
that is presuming that the database file has integrity -

LB has mature logics for handling database file read and write failure,
but it does not necessarily handle corrupt database file data well -
database file corruption could, apart from gracefully handled exception,
also lead to insidious incorrect value, failure to validate a block,
segfault, and thread lockup, all of which Eric has seen.


Therefore, given that your CPU&RAM&controllers & other software are all
in integrity, for LB to be in a "safe spot" you also need the
*underlying filesystem* to implement strong data integrity guarantees.


On 2016-05-17 13:14, Eric Voskuil wrote:
>> Now, what if the database is found to be [in]correct at runtime
>
> The database could be determined to be *potentially* corrupted at
> startup. This is not too hard, but not yet implemented. I've been
> considering it for version3. In this implementation the node would
> simply state that the store is corrupt and shut down.
>
> It would be up to the administrator to either override this warning (by
> deleting the sentinel file that indicates the corruption) or deleting
> the store and (1) re-synchronizing, or (2) restoring from backup.
>
> Once the node is running there is no potential for corruption short of
> hardware failures (including hard shutdown) or software bugs. These
> aren't things that can reasonably be guarded against at runtime.
> Hardware faults should be monitored at a lower level, and software
> quality is not a runtime issue.
>
>> what logics and exceptions are in place to handle that, are there
> guarantees that LibBitcoin will not SIGSEGV, go into undefined
> behavior,
> etc.?
>
> No software or hardware can implement such guarantees. Someone selling
> software could financially compensate customers for such failures, but
> I
> don't know anyone who does except possibly under MILSPEC contracts.
>
> e