death

[Stephen Weeks]

> Note, the point where  I  called  invariant()  by  hand  was  just  afer  the
> LimitCheck  macro  before  the  array  creation.  Assuming this is ok (and it
> seems to be from my reading of the ccodegen.h macros), this means that it  is
> the  mutator  code in the case of the short read or in the case of the 0 read
> that is causing the problem.

It looks to me like there are only a handful (tens) of SSA statements
between the call to invariant and the call to MLton_exit.  It should
be easy enough for you to isolate which one is causing the gc
invariant to be violated.  I can't do it because I can't run the code,
but there are only a few basic blocks involved.  There are are few
possible causes for the problem.
  1. The array being passed to Posix_IO_read isn't as long as we
     think it is.
  2. The offset or size being passed to Posix_IO_read is wrong
  3. The array isn't entirely contained in from-space.
  4. The arrays overlap with each other or some other object.

I think the best guess is to put invariant checks before and after
Posix_IO_read, since it is the likely culprit.

As an aside, I think the SML source code is a bit strange because you
pass around the size of res in the loop.  It is redundant to do so,
and I suspect is slower as well.