and then running ocamldumpobj on the resulting object file yields
output containing the instruction:

28 CLOSUREREC 0, 4294967298, 4294967311

which seems incorrect. From examining interp.c, CLOSUREREC seems to
take a count of variables and a number of function bytecode addresses,
and dumpobj.ml is outputting the operands in that order, but it's also
erroneously adding 2^32 to the addresses. E.g., the above line should
probably read:

28 CLOSUREREC 0, 2, 15

Additional Information

This is on Debian GNU/Linux, unstable variant, AMD64 architecture,
with OCaml 3.10.2, Debian OCaml package version 3.10.2-3. A glance at
tools/dumpobj.ml seems to indicate that what's happening is that the
offset is being treated as unsigned (comment mine for annotation):

This probably works on 32-bit machines because the Caml integers wrap
around properly in that case anyway, but on a 64-bit architecture,
there's more range in a Caml int and so treating the 32-bit offset as
an unsigned int rather than a signed one causes errors in bits 32 and
above in the result.