X-Recipient: archive-cygwin AT delorie DOT com X-Spam-Check-By: sourceware.org Date: Mon, 18 Jun 2012 16:51:48 +0200 From: Corinna Vinschen To: cygwin AT cygwin DOT com Subject: Re: Problem with MAP_PRIVATE for fork() using pypy Message-ID: <20120618145148.GD26243@calimero.vinschen.de> Reply-To: cygwin AT cygwin DOT com Mail-Followup-To: cygwin AT cygwin DOT com References: <1339287593 DOT 67918 DOT YahooMailNeo AT web162901 DOT mail DOT bf1 DOT yahoo DOT com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <1339287593.67918.YahooMailNeo@web162901.mail.bf1.yahoo.com> User-Agent: Mutt/1.5.21 (2010-09-15) Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm Precedence: bulk List-Id: List-Unsubscribe: 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 On Jun 9 17:19, Uwe F. Mayer wrote: > I have recently patched pypy (http://www.pypy.org) to compile under > Cygwin. Pypy implements a Python interpreter with a Just In Time (JIT) > compiler. At runtime pypy uses a MAP_PRIVATE anonymous mmap to > allocate memory for its JIT. This seems to be cause of fork() calls > failing. A sample error message is included below. I have discussed > this problem at length with the pypy developers. The discussion is > online at: > > http://www.mail-archive.com/pypy-dev AT python DOT org/msg02448.html  > > Finally I hacked the pypy sources and replaced the MAP_PRIVATE > anonymous mmap allocation with MAP_SHARED at the place where pypy > allocates its JIT temporary memory, and the code runs fine (but that's > not a solution for pypy, as their JIT child and parent processes > likely will drift apart for any real non-toy program and do need > separate memory space). From what the pypy folks say, this is not a > pypy issue but a Cygwin issue. > [...] > PS Attached is an output of cygcheck, and the relevant portion of an strace. Unfortunately the "relevant portion" of the strace is not at all relevant to see what happens. The error message is weird. This should not occur at all if the memory address still exists in the parent. I can't reproduce it with a simple testcase (see below) either. I ran it on a 64 bit system so that the allocated memory area is in the large address area, just as in your scenario. If you could create a testcase in plain C which allows to reproduce the behaviour, it would help a lot to track down the cause. Corinna #include #include #include int main () { char *p; int sz = 2 * getpagesize (); int offset; int magic = 0x33; int pid; int rv; p = (char *) mmap (NULL, sz, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0); if (p == MAP_FAILED) { printf ("mmap() = MAP_FAILED\n"); return 1; } printf ("mmap() = %p\n", p); offset = getpagesize () + 0x42; p[offset] = magic; pid = fork (); switch (pid) { case (-1): printf ("fork() failed\n"); break; case (0): printf ("child alive\n"); sleep (1); printf ("child touching %p\n", &(p[offset])); printf ("child M[%p] = 0x%x\n", &(p[offset]), p[offset]); p[offset] = 0x44; printf ("child M[%p] = 0x%x\n", &(p[offset]), p[offset]); pid = fork (); switch (pid) { case (-1): printf ("fork() failed\n"); break; case (0): printf ("grandchild alive\n"); sleep (1); printf ("grandchild touching %p\n", &(p[offset])); printf ("grandchild M[%p] = 0x%x\n", &(p[offset]), p[offset]); sleep (2); printf ("grandchild M[%p] = 0x%x\n", &(p[offset]), p[offset]); break; default: printf ("child alive\n"); sleep (2); printf ("child touching %p\n", &(p[offset])); printf ("child M[%p] = 0x%x\n", &(p[offset]), p[offset]); p[offset] = 0x55; printf ("child M[%p] = 0x%x\n", &(p[offset]), p[offset]); break; } break; default: printf ("parent alive\n"); sleep (5); printf ("parent touching %p\n", &(p[offset])); printf ("parent M[%p] = 0x%x\n", &(p[offset]), p[offset]); break; } return 0; } -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple