X-Recipient: archive-cygwin AT delorie DOT com
DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org B650B3858439
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cygwin.com;
	s=default; t=1674214272;
	bh=gyD4nf3msxUXlvq1yi3TJ3aCw3/BUWD5VtQMaj4T2KM=;
	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=VK8/0bFJwnFR1PC6njkczaqlFqBwLbBYeGRpGJVg4YqT22HFhC1AP8NZBpA/V7AIC
	 mXduUXmtcwsv1b03zL18D95jIQjADlY6qcPIRILhtv4lYd+LtVY4kYe29GUDxtldff
	 z4Ibjt4lnqXi+zU2Wc8JdtXeCpv1B3NM0recO4iM=
X-Original-To: cygwin AT cygwin DOT com
Delivered-To: cygwin AT cygwin DOT com
Date: Fri, 20 Jan 2023 12:30:29 +0100
To: cygwin AT cygwin DOT com
Subject: Re: Error: child_copy: cygheap read copy failed.
Message-ID: <Y8p7VR4dXAZZDWmd@calimero.vinschen.de>
Mail-Followup-To: cygwin AT cygwin DOT com
References: <20230120125633 DOT 05136d9ae091b097fc9f9cf5 AT nifty DOT ne DOT jp>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20230120125633.05136d9ae091b097fc9f9cf5@nifty.ne.jp>
X-Provags-ID: V03:K1:kD4o/wIcxiHCFO9g1kMe9RJguB19c0IrnxjwvwnK+Z1tnegjbPU
 S3X0KrEX/aGbDyOxjqvsy6Ge6AJkNbV+XpnVFU7eL/Z7H44QKXSAgJ39BX1eIBZNibwqyKv
 +gUgOYRmencfWHr1rod0a7x5eiU1sZRwPce/JDKsUpuvu89k6U42f029BxKIkE3+DS8LYt0
 6BePZbnScZhLysUi0Beew==
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==
X-Spam-Status: No, score=-103.0 required=5.0 tests=BAYES_00, GIT_PATCH_0,
 GOOD_FROM_CORINNA_CYGWIN, KAM_DMARC_STATUS, RCVD_IN_DNSWL_NONE,
 RCVD_IN_MSPIKE_H2, SPF_FAIL, SPF_HELO_NONE,
 TXREP autolearn=ham autolearn_force=no version=3.4.6
X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on
 server2.sourceware.org
X-BeenThere: cygwin AT cygwin DOT com
X-Mailman-Version: 2.1.29
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>
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 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 AT vinschen DOT 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