[MLton] cygwoes

[Matthew Fluet]

>> Any word on the cygwin problem?
>
> I made a little progress.  The way I usually debug stuff on Cygwin is
> by cross compiling the regressions.  I don't see the signal B error
> that you do.  Rather, I see
>
>  VirtualFree release failed
>
> Hopefully they are related, although who knows.

I don't believe that the gcc/signal error is related to the VirtualFree 
error, though, like Stephen, I have been unable to get a newer version of 
MLton bootstrapped on Cygwin to determine if the gcc/signal error 
persists.

> The release has been right around the corner for over a month, the
> delay being due only to the Cygwin problem.  It would be great if you
> could fix it.  MLton might even be able to release!

I've looked into this a little.  VirtualFree fails with the error code 
487, which corresponds to "Attempt to access invalid address."  This is 
quite odd, as putting debuggin statements in reveals that the Windows_* 
memory management goes like:

...
Windows_mmapAnon(0x30000000, 1527808) = 0xffffffff
Windows_mmapAnon(0x28000000, 1527808) = 0xffffffff
Windows_mmapAnon(0x20000000, 1527808) = 0x20000000
Windows_mmapAnon(0x00000000, 16384) = 0x01690000
Windows_mmapAnon(0x00000000, 1531904) = 0x01730000
Windows_release(0x20000000, 1527808)

SO, it certainly appears that we are passing a VirtualAlloc address to 
VirtualFree.  Still, I was suspicious of requesting a specific starting 
address; if I change line 1319 of gc.c from
                         h->start = GC_mmapAnon ((void*)address, h->size);
to
                         h->start = GC_mmapAnon ((void*)NULL, h->size);
(i.e., ignoring the scan of the virtual address space), then the 
VirtualFree failure disappears and the mlton-compile executable terminates 
normally.

Unfortunately, I get a file I/O error if I attempt to complete the 
boostrapping:

$ make constants
Creating constants file.
/home/fluet/mlton/mlton.svn.HEAD/build/bin/mlton -build-constants true >tmp.c
openIn /home\fluet\mlton\mlton.svn.head\build\lib/target-map: No such file or directory
make: *** [constants] Error 1

Somehow, my path has been changed to lowercase (it should be 
mlton.svn.HEAD, not mlton.svn.head).  I renamed my path to the lowercase 
version, hoping to avoid that issue.

Indeed, I'm able to produce the constants .c file, but the system call 
failure seems to be back:

$ make constants
Creating constants file.
/home/fluet/mlton/mlton.svn.head/build/bin/mlton -build-constants true >tmp.c
/home/fluet/mlton/mlton.svn.head/build/bin/mlton -output tmp tmp.c
call to system failed with No child processes:
gcc -std=gnu99 -c -I/home/fluet/mlton/mlton.svn.head/build/lib/include -O1 -fno-strict-aliasing -fomit-frame-pointer -w -fno-strength-reduce -fschedule-insns -fschedule-insns2 -malign-functions=5 -malign-jumps=2 -malign-loops=2 -o /tmp/fileEZi09z.o tmp.c
make: *** [constants] Error 1
       5 [main] ? 544 fork_copy: cygheap pass 0 failed, 0x611548E0..0x6115A7C8, done 0, windows pid 3880, Win32 error 5

The extra "5 [mail] ? ..." error message appears to be coming from cygwin 
or windows, since it is sometimes printed after my shell returns.  I'm 
also left with a gcc.exe.stacktup file:
Exception: STATUS_ACCESS_VIOLATION at eip=6105B252
eax=00000000 ebx=00000000 ecx=00000000 edx=10015288 esi=00000000 edi=10014EA8
ebp=0022E208 esp=0022E1E0 program=C:\cygwin\bin\gcc.exe, pid 2644, thread main
cs=001B ds=0023 es=0023 fs=003B gs=0000 ss=0023
Stack trace:
Frame     Function  Args
0022E208  6105B252  (00000000, 00000000, 0000007F, 00000000)
0022E2F8  6105B394  (611344C8, 610E24B0, 00000080, 0022E3D8)
0022E3B8  6105B116  (0022E510, 00000040, 6111C000, 6111C032)
0022E508  6107578B  (10014CB4, 10014CD0, 0022E568, 0022E56C)
0022E588  6107B3B7  (0022ED1C, 00000001, 0022E5B0, 00910895)
0022E5D8  6107BC0D  (0022ED18, 0022ED1C, 6111CB60, 6111CC04)
0022E628  6107BD0D  (00000001, 00000730, 6115B670, 0022ED10)
0022E6C8  61022431  (1D9A4192, 01C5B87C, 5CCBC438, 01C5C940)
0022EC38  61022E39  (6115B5E0, 00010000, 00000000, 00000060)
0022EC58  61024E19  (0022ED00, 00000000, 00000060, 61120BDC)
0022ECA8  610916FD  (10014C40, 0022ED00, 00000000, 004013F1)
0022ED78  610844FF  (00000004, 00000000, 00000000, 004124C8)
0022EDF8  0040B793  (00000011, 10011268, 10010090, 610FCC86)
0022EFD8  61004DD2  (0022EFF0, 7C90FB6C, 7FFDA000, 7FFDF000)
0022FF88  6100594F  (00000000, 00000000, 00000000, 00000000)
End of stack trace


Unfortunately, all this suggests that there is a lot more broken under the 
current version of Cygwin than just the virtual memory management.