[MLton] cygwoes
Matthew Fluet
fluet@cs.cornell.edu
Tue, 4 Oct 2005 20:23:58 -0400 (EDT)
>> 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.