Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner AT cygwin DOT com Mail-Followup-To: cygwin AT cygwin DOT com Delivered-To: mailing list cygwin AT cygwin DOT com X-Originating-IP: [66.144.4.4] X-Originating-Email: [renfur AT hotmail DOT com] X-Sender: renfur AT hotmail DOT com From: "Ren Fur" To: cygwin AT cygwin DOT com Subject: 1.5.10: Possible fork() bug: certain addresses inaccessible to child (Win2000) Date: Sun, 04 Jul 2004 19:51:50 -0400 Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_33c2_1fc5_6b68" Message-ID: X-OriginalArrivalTime: 04 Jul 2004 23:51:51.0129 (UTC) FILETIME=[E063B490:01C46221] Note-from-DJ: This may be spam ------=_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--