From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mout.kundenserver.de (mout.kundenserver.de [212.227.126.187]) by sourceware.org (Postfix) with ESMTPS id C449F3858D1E for ; Fri, 20 Jan 2023 11:30:32 +0000 (GMT) Authentication-Results: sourceware.org; dmarc=permerror header.from=cygwin.com Authentication-Results: sourceware.org; spf=fail smtp.mailfrom=cygwin.com Received: from calimero.vinschen.de ([24.134.7.25]) by mrelayeu.kundenserver.de (mreue011 [212.227.15.167]) with ESMTPSA (Nemesis) id 1MbAxU-1ohYyc442S-00baNS for ; Fri, 20 Jan 2023 12:30:31 +0100 Received: by calimero.vinschen.de (Postfix, from userid 500) id 940BAA80716; Fri, 20 Jan 2023 12:30:29 +0100 (CET) Date: Fri, 20 Jan 2023 12:30:29 +0100 From: Corinna Vinschen To: cygwin@cygwin.com Subject: Re: Error: child_copy: cygheap read copy failed. Message-ID: Reply-To: cygwin@cygwin.com Mail-Followup-To: cygwin@cygwin.com References: <20230120125633.05136d9ae091b097fc9f9cf5@nifty.ne.jp> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 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 List-Id: 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 > 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