On Jan 15 17:59, Corinna Vinschen wrote:
> 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.
Alternatively it has to be faked in the affected functions, which then
stealthily only access the pages up to EOF under the hood...
Corinna
