X-Recipient: archive-cygwin AT delorie DOT com
DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 4776B385AC33
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cygwin.com;
	s=default; t=1707904381;
	bh=5b9M1fwkqv+7rMGLC7N5BS9U9fSZ7TzRoXK0sztNpn0=;
	h=Date:To:Subject:References:In-Reply-To:List-Id:List-Unsubscribe:
	 List-Archive:List-Post:List-Help:List-Subscribe:From:Reply-To:Cc:
	 From;
	b=HeHyyQcCedN+ncSXXgifNWMHzrVw7sAmGPuzZvtp/RqMcboFt+DTPCptaTqD2p5sg
	 iI6HdSzdr5zjaivV6UjFGa0+356n5/lci+8D3dqASOkZ+sktPI3Yk++GaTZq9R3nRU
	 OO3fEsB+aUBcwbjq4wnzU/ZPaimkb7WqaJlRz2bg=
X-Original-To: cygwin AT cygwin DOT com
Delivered-To: cygwin AT cygwin DOT com
DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org E6321385AC20
Date: Wed, 14 Feb 2024 10:52:12 +0100
To: Kevin Ushey <kevinushey AT gmail DOT com>
Subject: Re: Cygwin installer hangs when running post-install scripts
Message-ID: <ZcyNTIuY728RhUTg@calimero.vinschen.de>
Mail-Followup-To: Kevin Ushey <kevinushey AT gmail DOT com>, cygwin AT cygwin DOT com
References: <CAJXgQP0ZpcQXON_oKbgE=S8Y-M=9+b00cZ6s4Het01TCTp3ajA AT mail DOT gmail DOT com>
 <Zcs_54Sakt48iAUd AT calimero DOT vinschen DOT de>
 <ZcuYBL3D2rSjlhNu AT calimero DOT vinschen DOT de>
 <CAJXgQP3YzDiomDUvOG30JfSAbe5d3EgLDRvbsT8yN73aAswPLA AT mail DOT gmail DOT com>
 <Zcu761ZXudxviCKv AT calimero DOT vinschen DOT de>
 <CAJXgQP3L5Wq9ZmVUJ2K+wt04Nh15QTjt2e9SF07TYwS8Bg15rg AT mail DOT gmail DOT com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <CAJXgQP3L5Wq9ZmVUJ2K+wt04Nh15QTjt2e9SF07TYwS8Bg15rg@mail.gmail.com>
X-BeenThere: cygwin AT cygwin DOT com
X-Mailman-Version: 2.1.30
Precedence: list
List-Id: General Cygwin discussions and problem reports <cygwin.cygwin.com>
List-Unsubscribe: <https://cygwin.com/mailman/options/cygwin>,
 <mailto:cygwin-request AT cygwin DOT com?subject=unsubscribe>
List-Archive: <https://cygwin.com/pipermail/cygwin/>
List-Post: <mailto:cygwin AT cygwin DOT com>
List-Help: <mailto:cygwin-request AT cygwin DOT com?subject=help>
List-Subscribe: <https://cygwin.com/mailman/listinfo/cygwin>,
 <mailto:cygwin-request AT cygwin DOT com?subject=subscribe>
From: Corinna Vinschen via Cygwin <cygwin AT cygwin DOT com>
Reply-To: cygwin AT cygwin DOT com
Cc: Corinna Vinschen <corinna-cygwin AT cygwin DOT com>, cygwin AT cygwin DOT com
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Errors-To: cygwin-bounces+archive-cygwin=delorie DOT com AT cygwin DOT com
Sender: "Cygwin" <cygwin-bounces+archive-cygwin=delorie DOT com AT cygwin DOT com>

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