On Dec  1 22:44, David Macek wrote:
> On 1. 12. 2015 18:40, David Macek wrote:
> > On 1. 12. 2015 15:01, Corinna Vinschen wrote:
> >> On Dec  1 21:07, nu774 wrote:
> >>>> There must be a bug in the new CMD somewhere.  But, anyway, I'll look
> >>>> into it when I finally managed to update my W10 test machine.
> >>>
> >>> No, cmd.exe is just an example. Any 32bit process can be an trigger.
> >>> I guess something has changed in TH2 kernel regarding process memory
> >>> management or something that interferes cygwin's fork().
> >>
> >> If that only happens w/ 64 bit Cygwin started from a 32 bit parent, then
> >> there's some foul-up in the WOW64 layer in terms of starting 64 bit
> >> processes, perhaps.  Sigh, it's a rather unexpected change after it
> >> worked fine for so long :(
> > 
> > Yup. I can confirm.
> 
> Just for the record, we did some debugging over IRC and it seems it's an issue with WOW64 where the stack in the first 64-bit process is offset for some reason.
> 
> Citing Corinna: "I wonder if we have to resurrect the old wow64_respawn_process function for this border case"

Along these lines, is anybody here still running a 64 bit Windows 10
which has *NOT* been updated to 1511?  If so, I just need the output
of a call to `cat /proc/self/maps' once for comparison.


Thanks in advance,
Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Maintainer                 cygwin AT cygwin DOT com
Red Hat