I finally fixed this. The difficulty was down to the sheer number of
different causes:

During incremental updates (but not bulk updates) the wrong data
structure was marshaled to disk so the next process to load from the
disk would segfault

DynArray contains functional values so compiling with -g breaks
previously marshaled values

Marshal segfaults on large data structures unless 'ulimit -s unlimited' is set

List.merge is not tail recursive and segfaults on large lists unless
'ulimit -s unlimited' is set (this only happens during bulk updates)

On 32 bit machines the arrays used in the suffix array are too large,
in older versions of ocaml this causes a segfault

I'm still not sure why gdb reliably tracked a segfault to
caml_ml_close_channel but the very next instruction was accessing the
data structure marshaled from disk.

I do feel that this would have been much easier to fix if ocaml raised
more informative errros. The change to Array.make and String.make to
raise exceptions instead of segfaulting is welcome. Is there a way to
cause stack overflows to raise exceptions in native compiled ocaml as
well?