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
