Windows 8 Release Preview. fork problems with rsync

Nick Lowe nick.lowe@gmail.com
Wed Jun 6 16:59:00 GMT 2012


Urgh! Hmm.. Do you see the same effect when running the process in
question under the Windows 8 operating system context?

If you manifest and include:

<compatibility xmlns="urn:schemas-microsoft-com:compatibility.v1">
      <application>
         <!--The ID below indicates application support for Windows Vista -->
<supportedOS Id="{e2011457-1546-43c5-a5fe-008deee3d3f0}"/>
<!--The ID below indicates application support for Windows 7 -->
<supportedOS Id="{35138b9a-5d96-4fbd-8e2d-a2440225f93a}"/>
<!--The ID below indicates application support for Windows 8 -->
<supportedOS Id="{4a2f28e3-53b9-4441-ba9c-d69d4a4a6e38}"/>
      </application>
  </compatibility>
http://msdn.microsoft.com/en-us/library/windows/desktop/hh848036(v=vs.85).aspx

Does the odd behaviour still persist?

Could it be possibly be something to do with the fault tolerant heap
(FTH) and changes they've made to it? I would try ensuring that is
switched off too...

(Process Hacker will show the context of a running process.)

Nick

> Thanks.  I can confirm the effect.  For no apparent reason, the OS
> reserves a 1 Megs shared memory region, top-down allocated, of which it
> uses about 20K.  It's not the PEB or one of the TEBs, though.  Nor is
> it a thread stack.  I checked, and it turns out that it's allocated
> in every process, on 32 and 64 bit systems.  That's kind of worrying
> since that's bound to collide with mmaped regions and pthread stacks a
> lot.  I don't know what to do at this point.

--
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



More information about the Cygwin mailing list