mmap failure [was: cygrunsrv + sshd + rsync = 20 times too slow -- throttled?]

[Peter Dons Tychsen]

Hi there,

On Mon, 2021-09-06 at 14:40 -0400, Ken Brown via Cygwin wrote:
> > No, wait.  I get what you say.  The optimzation settings of the test
> > case should have no influence on the code inside the DLL.  That
> > doesn't
> > make sense for sure.  However, I ran the testcase under GDB, I could
> > reproduce the issue, and I could fix it by setting mmap_ext.Reserved
> > = 0;
> > Go figure!
> 
> I don't get it, but I can confirm that the problem is fixed.

That sounds a bit like a voodoo fix, that could quickly regress again.

Here is my 2 cents:

Currently the mmap_ext structure is setup like this:

 215       MEM_EXTENDED_PARAMETER mmap_ext = {
 216         .Type = MemExtendedParameterAddressRequirements,
 217         .Pointer = (PVOID) &mmap_req
 218       };

This means that all other entries in the struct are zero at
initialization as described here:
https://en.cppreference.com/w/c/language/struct_initialization

So if you set "mmap_ext.Reserved = 0" again after that its a double
failure. 

1) The compiler should ignore it as it is redundent.
2) It makes no sense, as it is already zero :-)

Since it is not ignored, the compiler clearly puts in code to to
reinitialize the variable (which some compilers do not optimize for).

The reason this makes it "work" it probably because of some other stack
curruption that is going on which then disappears because of the code
moving around a bit due to the new line. My best guess would be that
other fun stuff in the same location would also "fix" the problem.

These are not the droids you are looking for. The real problem is
elsewhere, and is likely due to some stack-smashing going on. This is
also likely why recompiling the test program makes a difference as that
changes what goes on the variable stack. When the code moves around
again (e.g. new compiler version), it could break again.

Looking at the test program -02 vs -O0:

pushq	%rbp
.seh_pushreg	%rbp
movq	%rsp, %rbp
.seh_setframe	%rbp, 0
subq	$64, %rsp
.seh_stackalloc	64
.seh_endprologue

vs

subq	$56, %rsp
.seh_stackalloc	56

Which gives a different stack layout. I think the problem must be in
the start of mmap() or subsequent calls like CreateMapping() and
MapView(). Something smashes or affects the stack.

Thanks,

/pedro