Date: Fri, 20 Jan 2023 12:30:29 +0100
To: cygwin@cygwin.com
Subject: Re: Error: child_copy: cygheap read copy failed.
Message-ID: <Y8p7VR4dXAZZDWmd@calimero.vinschen.de>
Mail-Followup-To: cygwin@cygwin.com
References: <20230120125633.05136d9ae091b097fc9f9cf5@nifty.ne.jp>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20230120125633.05136d9ae091b097fc9f9cf5@nifty.ne.jp>
UI-OutboundReport: notjunk:1;M01:P0:WELjLzvznCM=;MwKueYF9qXrjhWsDMMBuBd/iWmW
 NgA1yY71IuP128VyhhDtsefFXA0v8VjYih9orSrWcY6TFRwKdcsSbszGylb3tZ0AFDrwwuQ10
 HpbbgftK+S59k/dGQrzpvoTpUvm6r9Q9zztiV9OiPzlvZFFKozFVXbj8FUSg1qUSBaCfVGAcM
 cHADITRkY6AR2KE5kO6AnJb0Ho9ltaf2WeVr+3u+5DLmvfS5gilssHAzkw7gM2Iupc45zYujr
 abefOdG0Y7BesNhky/SjgWvvbCnHGMeMsNbGZ7b3V/fCf5OW/mjJ90L7LnIYF5KsVoAmKW+4T
 OGmI7gyY9wn3XcwbgWxifjc7HjOIDSknPeFDpPuX5QLKeAguSt7vv+x5nAbT+Sw8Xb+8iEcfi
 PzeZ7OpC66G0OvwtxlyckbOr6P4pVrJqFF+KmC/T/2DthVriCxm9Dod2EA6xRD16eNC/IKr0f
 dTnG8yHXUsrQ+/JMviKWBm14wgcAk8ZHVPC4xWhOPWmEtBY6uEKLmlazkO2sWS2S2KhPPHNvV
 SXLtrifULeqB+FsuRw+IDOpAE3N6rCtIb0GPUxui5EDJQE3oLdWNvXooEN74qsz1DR0Wkhija
 ksXvnVVG+DOU3nliHvjsu+Mk0cNkNEGKYFxikiVxBBziw0pHoZrgoXY0hhegBloKXuIary6gn
 AAR9HmXUimhqRpGViAiNanzmx9mhQUOyGAQzxQs4IQ==
Precedence: list
From: Corinna Vinschen via Cygwin <cygwin@cygwin.com>
Reply-To: cygwin@cygwin.com
Cc: Corinna Vinschen <corinna-cygwin@cygwin.com>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Errors-To: cygwin-bounces+archive-cygwin=delorie.com@cygwin.com
Sender: "Cygwin" <cygwin-bounces+archive-cygwin=delorie.com@cygwin.com>

On Jan 20 12:56, Takashi Yano via Cygwin wrote:
> Hi Corinna,
> 
> I am now working on porting ffmpeg for cygwin, and noticed that
> the following error sometimes happens.
> 
> $ while true; do ffplay 2>&1 |grep cygheap; done
>       0 [main] ffplay (10172) child_copy: cygheap read copy failed, 0x0..0x800028FB8, done 0, windows pid 10172, Win32 error 299
> 
> This seems to happen after the commit:
> 
> commit 2f9b8ff00cce0d0ceeb1091b6b9aecae914ddb89
> Author: Corinna Vinschen <corinna@vinschen.de>
> Date:   Wed Oct 26 21:16:35 2022 +0200
> 
>     Cygwin: decouple cygheap from Cygwin DLL
> [...]
> I looked into this problem a bit and found that VirtualAlloc()
> for MEM_RESERVE of cygheap area in cygheap_fixup_in_child()
> failed with ERROR_INVALID_ADDRESS. It seems that the address
> range is already occupied for some reason.

You should try to find out what that is.
> 
> I also noticed that the following patch seems to resolve the issue.
> 
> diff --git a/winsup/cygwin/local_includes/memory_layout.h b/winsup/cygwin/local_includes/memory_layout.h
> index a3a0cae70..67164cfaf 100644
> --- a/winsup/cygwin/local_includes/memory_layout.h
> +++ b/winsup/cygwin/local_includes/memory_layout.h
> @@ -44,15 +44,15 @@ details. */
>  
>  /* That's where the cygheap is located. CYGHEAP_STORAGE_INITIAL defines the
>     end of the initially committed heap area. */
> -#define CYGHEAP_STORAGE_LOW		0x800000000UL
> -#define CYGHEAP_STORAGE_INITIAL		0x800300000UL
> -#define CYGHEAP_STORAGE_HIGH		0xa00000000UL
> +#define CYGHEAP_STORAGE_LOW		0x70000000000UL
> +#define CYGHEAP_STORAGE_INITIAL		0x70000300000UL
> +#define CYGHEAP_STORAGE_HIGH		0x70200000000UL
>  
>  /* This is where the user heap starts.  There's no defined end address.
>     The user heap pontentially grows into the mmap arena.  However,
>     the user heap grows upwards and the mmap arena grows downwards,
>     so there's not much chance to meet unluckily. */
> -#define USERHEAP_START			0xa00000000UL
> +#define USERHEAP_START			0x800000000UL

That doesn't make sense.  So we now have the user heap in place of the
cygheap, and that works?  So why should anything occuping the 0x800000000
- 0xa00000000 area if the cygheap needs it, suddenly not occupy it when
the user heap needs it?

Of course, this could be a result of the user heap not being reserved in
full size like the cygheap is.  The fact that it works with your patch
above points to an incidental success, with the user heap keeping most
of the area from 0x800000000 - 0xa00000000 free.  It would then fail
only later, if the application tries to raise the user heap beyond a
certain size.

Right now this looks like a very special case.  I don't know what I
should do from my side.  Please add debug output and/or use vmmap
from sysinternals to find out what's actually occupying the area
from 0x800000000 - 0xa00000000 and where exactly.

Also, your ffplay executable isn't high-entropy-VA enabled, by any
chance?


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