Re: Error: child_copy: cygheap read copy failed.

[Corinna Vinschen <corinna-cygwin@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