DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org E877C3858CDA
Date: Fri, 20 Jan 2023 12:56:33 +0900
To: cygwin AT cygwin DOT com
Subject: Error: child_copy: cygheap read copy failed.
Message-Id: <20230120125633.05136d9ae091b097fc9f9cf5@nifty.ne.jp>
Mime-Version: 1.0
From: Takashi Yano via Cygwin <cygwin AT cygwin DOT com>
Reply-To: Takashi Yano <takashi DOT yano AT nifty DOT ne DOT jp>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: "Cygwin" <cygwin-bounces+archive-cygwin=delorie DOT com AT cygwin DOT com>

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
      0 [main] ffplay (13052) child_copy: cygheap read copy failed, 0x0..0x800028FB8, done 0, windows pid 13052, Win32 error 299
      0 [main] ffplay (9092) child_copy: cygheap read copy failed, 0x0..0x800028FB8, done 0, windows pid 9092, Win32 error 299
      0 [main] ffplay (8988) child_copy: cygheap read copy failed, 0x0..0x800028FB8, done 0, windows pid 8988, Win32 error 299
      0 [main] ffplay (11800) child_copy: cygheap read copy failed, 0x0..0x800028FB8, done 0, windows pid 11800, Win32 error 299
      0 [main] ffplay (6088) child_copy: cygheap read copy failed, 0x0..0x800028FB8, done 0, windows pid 6088, 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

    One reason that ASLR is tricky is the fact that the cygheap
    is placed at the end of the DLL and especially that it's expected
    to be growable.  To support ASLR, this construct must go.

    Define dedicated cygheap memory region and reserve entire region.
    Commit 3 Megs, as was the default size of the cygheap before.

    Fix linker script accordingly, drop a now useless version check
    in get_cygwin_startup_info().

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.

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			0x00800000000UL
 
 /* The memory region used for memory maps.  Mmaps grow downwards.
    Set the lowest address to leave ~32 Gigs for heap.

Could you please have a look?

-- 
Takashi Yano <takashi DOT yano AT nifty DOT ne DOT jp>

-- 
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