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
--
Problem reports: https://cygwin.com/problems.html
FAQ: https://cygwin.com/faq/
Documentation: https://cygwin.com/docs.html
Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
