Problem solved...

[ANOQ of the Sun]

"Stephen Weeks" wrote:
> I was able to duplicate the error you saw.  I tried running it with
> fixed-heap, and that failed as well.  As I don't have a decent windows
> debugging environment I don't see how to help much more in the windows
> world.

Here's what I figured out so far...

I looked through all the addresses allocated and
freed. The address that fails to be freed is the
only VirtualFree-address which has not been allocated
at all! And the VirtualFree error code is 487 - which
means invalid address.

The VirtualFree address of the failure is currently
0x5e50000 on my system. And the closest addresses
which were allocated are 0x5e10000 and 0x5e90000.
0x5e10000 had just been allocated but not freed
before the error, and 0x5e90000 had just been freed
already.

Also I've tried with another inputfile - same problem,
except that the VirtualFree address of the failure is
0x4160000 and the closest allocations are at
0x4140000 and 0x4180000. Again, 0x4180000 had been
freed again earlier but 0x4140000 had not.

Also, when I run the program with the same input
several times (even after reboot) the alloc/free
addresses are the same, so it seems to be very
systematic.

So it seems to me that some address is calculated wrong
during some address arithmetic. In these cases
it could be that either 0x40000 or 0x20000 is added
to the address.

Notice that the second input file is only about half
the size of the first - which might explain the 0x40000
vs. 0x20000. Also with a 3rd input file (about the
same size as the second) the pattern is the same,
and the "error" is also 0x20000.

Also, I had earlier set a constant of about 16MB for
the "total available memory" which is used in the code.
When I change this to about 32MB, nothing changes -
so it doesn't seem to have reached that memory-limit.

I still haven't got any good overview of gc.c - so I'm
not sure where to search for this "behaviour" in the code...

> If you get desperate, more recent (internal) versions of MLton have a
> modified runtime that allocates the stack within the heap.  Thus there
> are only two chunks of memory, fromspace and tospace.  I could let you
> have one of those to try out before the next MLton release.

Would that be more or less efficient than the current scheme?
I know that SML/NJ did something like this earlier, but
I believe that they changed it back again, since using the
stack was faster.


Cheers
-- 
http://www.HardcoreProcessing.com