Mail Archives: cygwin/2024/02/14/04:53:03
On Feb 13 15:48, Kevin Ushey via Cygwin wrote:
> Here's a bit more information from a debug build of cygwin; here I'm
> just trying to launch cygpath.exe:
>
> (gdb) f 1
> #1 0x00007ffa0123ba1f in find_fast_cwd_pointer () at
> ../../../../winsup/cygwin/path.cc:4526
> 4526 const uint8_t *lock = (const uint8_t *)
>
> (gdb) bt
> #0 memmem (haystack=<optimized out>, hs_len=<optimized out>,
> needle=0x7ffa0142e531 <_C_collate_locale+59857>, ne_len=4) at
> ../../../newlib/libc/string/memmem.c:161
> #1 0x00007ffa0123ba1f in find_fast_cwd_pointer () at
> ../../../../winsup/cygwin/path.cc:4526
> [...]
Ok, so we know now which memmem call fails, so the next question is,
why? The haystack address is unfortunately still optimized out in
memmem, so it looks like the newlib subdir is still optimized.
But it's pretty certainly a wrong haystack address. This address has
been fetched from
const uint8_t *rcall = (const uint8_t *) memchr (get_dir, 0xe8, 80);
...
const uint8_t *use_cwd = rcall + 5 + peek32 (rcall + 1);
Chances are high, that the call instruction found by rcall is bogus.
> Diving in further is a bit beyond my level of experience with Windows
> internals.
It would be great if you could run this under GDB and check the
assembler code inside the ntdll.dll this code is scanning. You
don't really need knowledge of Windows internals, it's basically
just really dumb scanning of assembler code for certain instructions,
and the expected assembler code is x86_64.
> I wonder if it'd be
> worth having cygwin respect an environment variable like
> CYGWIN_USE_FAST_CWD_POINTER, so that users could opt out of this
> particular optimization if it happens to break on new versions of
> Windows, as I have seemingly encountered.
My latest patch already does it, no env var required.
> As an aside, I had to make a couple of small patches to side-step gcc
> warnings (converted to errors) during build; I tried building with "-g
> -Og" flags.
I'm usually building with -ggdb only, or with -ggdb -O2.
I just added -Og, and checked the below code. I'm not so sure about the
usefulness of -Og, given that all three warnings are false positives...
> $ git diff
> diff --git a/winsup/cygwin/fhandler/fifo.cc b/winsup/cygwin/fhandler/fifo.cc
> index efea508ae..f288e874a 100644
> --- a/winsup/cygwin/fhandler/fifo.cc
> +++ b/winsup/cygwin/fhandler/fifo.cc
> @@ -669,7 +669,7 @@ fhandler_fifo::create_shmem (bool only_open)
> {
> HANDLE sect;
> OBJECT_ATTRIBUTES attr;
> - NTSTATUS status;
> + NTSTATUS status = 0;
> LARGE_INTEGER size = { .QuadPart = sizeof (fifo_shmem_t) };
> SIZE_T viewsize = sizeof (fifo_shmem_t);
> PVOID addr = NULL;
My gcc (11.3.0) did not show this, even with -Og. However, the status
var always gets set, see lines 685 - 695.
> diff --git a/winsup/cygwin/tty.cc b/winsup/cygwin/tty.cc
> index bf7c6010f..2cd4ae6ed 100644
> --- a/winsup/cygwin/tty.cc
> +++ b/winsup/cygwin/tty.cc
> @@ -323,7 +323,7 @@ tty::wait_fwd ()
> thread when the last data is transfered. */
> const ULONGLONG sleep_in_nat_pipe = 16;
> const ULONGLONG time_to_wait = sleep_in_nat_pipe * 2 + 1/* margine */;
> - ULONGLONG elapsed;
> + ULONGLONG elapsed = 0;
> while (fwd_not_empty
> || (elapsed = GetTickCount64 () - fwd_last_time) < time_to_wait)
> {
fwd_not_empty is false for a start, so GetTickCount64() is called at
least once.
> diff --git a/winsup/utils/kill.cc b/winsup/utils/kill.cc
> index fb45e4c9d..bcabcd47c 100644
> --- a/winsup/utils/kill.cc
> +++ b/winsup/utils/kill.cc
> @@ -73,7 +73,7 @@ print_version ()
> static const char *
> strsigno (int signo)
> {
> - static char sigbuf[8];
> + static char sigbuf[32];
>
> if (signo > 0 && signo < SIGRTMIN)
> return sys_sigabbrev[signo];
We're calling snprintf here for a reason, and we know that the
number has never more than 2 digits. Oh well.
Thanks,
Corinna
--
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
- Raw text -