Mail Archives: cygwin/2004/07/04/19:51:57
------=_NextPart_000_33c2_1fc5_6b68
Content-Type: text/plain; format=flowed
I have a program written in SML (fork.sml) and compiled with MLton
(www.mlton.org) that relies on fork() and uses a foreign function call to a
C wrapper (fork_wrapper() in fork.c).
When I run the program, both parent and child return from the fork() call
and from the C wrapper function. However, the child is terminated soon after
because it tries to access an "illegal" memory address (but this address is
visible to the parent before and after the fork). I have stepped through the
parent and child's execution with gdb and found that the memory the child
tries to access is in the parent's address space but not in the child's.
I haven't found any Cygwin reports of this problem, but it's known to the
MLton developers since the library fork function (Posix.Process.fork) is
disabled on the Cygwin version of MLton.
I have been able to repeat this behavior on several Windows 2000 computers
running Cygwin 1.5.10. I'm using the MLton 20040227 compiler for Cygwin.
www.mlton.org/download/index.html
www.mlton.org/download/mlton-20040227-1.i386-cygwin.tgz
After compiling the SML program, I disassembled the binary and found the
following. (The numbers and addresses here are host- and run-dependent.)
-The block with label L_1047 calls fork_wrapper().
-Before calling fork_wrapper(), %esp and %ebp are stored at 0x41d560 and
0x41d568, respectively.
-After fork_wrapper() returns, %esp and %ebp are restored from those
adresses.
-On one run, before calling fork_wrapper(), the parent had %esp = 0x00a92e4c
and %ebp = 0x00a90b9c, and both addresses could be dereferenced. After
fork_wrapper() returned, the child could dereference 0x00a90b9c (%ebp) but
not 0x00a92e4c (%esp). gdb would report the memory at that address was
inaccessible, and if the child continued it would get a SIGSEGV. I don't
know what page size Windows uses, but it seems like those two addresses
would be in the same page, which makes the problem stranger.
Also, fork() does work if it's used in a regular C program.
Is this a Cygwin bug or am I missing something when using fork()?
Thank you.
_________________________________________________________________
Express yourself instantly with MSN Messenger! Download today - it's FREE!
http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/
------=_NextPart_000_33c2_1fc5_6b68
Content-Type: application/octet-stream; name="Makefile"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="Makefile"
Zm9yazogZm9yay5jIGZvcmsuc21sCglnY2MgLVdhbGwgLWMgZm9yay5jCglt
bHRvbiBmb3JrLnNtbCBmb3JrLm8K
------=_NextPart_000_33c2_1fc5_6b68
Content-Type: application/octet-stream; name="fork.sml"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="fork.sml"
KCogaW1wb3J0IGZvcmVpZ24gZnVuY3Rpb24gKikKdmFsIGZvcmsgPSBfaW1w
b3J0ICJmb3JrX3dyYXBwZXIiIDogdW5pdCAtPiBpbnQ7CigqIGZvcmsgYW5k
IHByaW50IGZyb20gY2hpbGQgYW5kIHBhcmVudCAqKQp2YWwgXyA9CiAgY2Fz
ZSBmb3JrICgpIG9mCiAgICAgIDAgPT4gcHJpbnQgIltNTF0gY2hpbGRcbiIK
ICAgIHwgcGlkID0+IHByaW50ICgiW01MXSBwYXJlbnQgb2YgIiBeIEludC50
b1N0cmluZyBwaWQgXiAiXG4iKQ==
------=_NextPart_000_33c2_1fc5_6b68
Content-Type: application/octet-stream; name="fork.c"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="fork.c"
I2luY2x1ZGUgPHN0ZGlvLmg+CiNpbmNsdWRlIDx1bmlzdGQuaD4KCmludCBm
b3JrX3dyYXBwZXIoKQp7CiAgaW50IHBpZDsKCiAgcGlkID0gZm9yaygpOwoK
ICBwcmludGYoIltDXSBwcm9jZXNzICVkXG4iLHBpZCk7CgogIC8qIGVub3Vn
aCB0aW1lIGZvciBnZGIgdG8gYXR0YWNoIHRvIGNoaWxkICovCiAgc2xlZXAo
MjApOwoKICByZXR1cm4gcGlkOwp9Cg==
------=_NextPart_000_33c2_1fc5_6b68
Content-Type: text/plain; charset=us-ascii
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
------=_NextPart_000_33c2_1fc5_6b68--
- Raw text -