[PATCH] Cygwin: mmap: use 64K pages for bookkeeping

[Corinna Vinschen]

On Jan 15 11:36, Ken Brown wrote:
> On 1/15/2025 8:17 AM, Takashi Yano wrote:
> > With this patch, gdb no longer works in my environment:
> > 
> > $ gdb
> > Pre-boot error; key: system-error, args: ("load-thunk-from-memory" "~A" ("Invalid argument") (22))
> > 
> > Fatal signal: Aborted
> > ----- Backtrace -----
> > ---------------------
> > A fatal error internal to GDB has been detected, further
> > debugging is not possible.  GDB will now terminate.
> > 
> > This is a bug, please report it.  For instructions, see:
> > <https://www.gnu.org/software/gdb/bugs/>.
> > 
> > Abort
> > $
> > 
> > Any idea?
> 
> I ran gdb under strace and saw the following:
> 
> 
>   125 6200747 [main] gdb 25844 mprotect: mprotect (addr: 0x6FFFFFA50000, len
> 7584, prot 0x3)
>   122 6200869 [main] gdb 25844 seterrno_from_win_error:
> ../../../../winsup/cygwin/mm/mmap.cc:1290 windows error 487
>   141 6201010 [main] gdb 25844 geterrno_from_win_error: windows error 487 ==
> errno 22
>   133 6201143 [main] gdb 25844 mprotect: -1 = mprotect (), errno 22
> [...]
>    65 6237537 [main] gdb 25844 mmap_record::unmap_pages: VirtualProtect in
> unmap_pages () failed, Win32 error 487
> 
> Windows error 487 is ERROR_INVALID_ADDRESS.
> 
> I'll try to figure out what's going on.  In the meantime, I've reverted the
> commit.

Ouch.  It looks like we can't go to 64K bookkeeping.  Windows files are
not length-aligned to 64K allocation granularity, but to 4K pagesize.
Thus, if we align the length to 64K in mprotect or
mmap_record::unmap_pages, it tries to access the unallocatd area from
the EOF page to the last page in the 64K area, which, obviously fails.

D'oh.

Sorry, I could have thought about this earlier :(


Corinna