As requested, I ran the code with strace. More precisely, I ran from the pypy/pypy/translator/goal/ directory the command: strace sh -c 'pypy-c /d/pypy/test_os_fork.py' I ran this twice, once with a version of pypy built with "--opt=2", and once with with a version of pypy built with "--opt=jit". The "--opt=2" version succeeds, and the "--opt=jit" version fails, as reported earlier. Attached you'll find the test_os_fork.py script, and the two log files cut down to the relevant part. The log is a couple of MB, I cut it down to the relevant section. I don't know the answers the other two questions. The third question may touch the core of the issue if the JIT marks the (parent) memory as exclusive access before the fork() call, which would be consistent with the observed error. From what I can tell the fork() call never gets off the ground, having no read access to duplicate the process image. --Uwe ________________________________ From: Amaury Forgeot d'Arc <amauryfa@gmail.com> To: Uwe F. Mayer <uwe_f_mayer@yahoo.com> Cc: Armin Rigo <arigo@tunes.org>; Matti Picus <matti.picus@gmail.com>; "pypy-dev@python.org" <pypy-dev@python.org> Sent: Thursday, June 7, 2012 2:24 PM Subject: Re: [pypy-dev] Patches for Pypy under cygwin 2012/6/7 Uwe F. Mayer <uwe_f_mayer@yahoo.com> 3 [main] pypy-c 11788 fixup_mmaps_after_fork: ReadProcessMemory failed for MAP_PRIVATE address 0xB0010000, Win32 error 998 Aha, looks interesting. Searching for this error message, I found that cygwin unblocks the parent process before the child calls "fixup_mmaps_after_fork": http://www.mail-archive.com/cygwin@cygwin.com/msg05547.html Could you try again with strace? Does the parent really unmap memory? Or is it because of the special access rights that the JIT uses to mark the memory as executable? -- Amaury Forgeot d'Arc