From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from sa-prd-fep-046.btinternet.com (mailomta5-sa.btinternet.com [213.120.69.11]) by sourceware.org (Postfix) with ESMTPS id 5B03A3858CDA for ; Wed, 2 Nov 2022 12:38:10 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 5B03A3858CDA Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=dronecode.org.uk Authentication-Results: sourceware.org; spf=none smtp.mailfrom=dronecode.org.uk Received: from sa-prd-rgout-005.btmx-prd.synchronoss.net ([10.2.38.8]) by sa-prd-fep-046.btinternet.com with ESMTP id <20221102123809.GXIS3113.sa-prd-fep-046.btinternet.com@sa-prd-rgout-005.btmx-prd.synchronoss.net>; Wed, 2 Nov 2022 12:38:09 +0000 Authentication-Results: btinternet.com; auth=pass (PLAIN) smtp.auth=jonturney@btinternet.com; bimi=skipped X-SNCR-Rigid: 6139452E416C4E7E X-Originating-IP: [81.153.98.206] X-OWM-Source-IP: 81.153.98.206 (GB) X-OWM-Env-Sender: jonturney@btinternet.com X-VadeSecure-score: verdict=clean score=0/300, class=clean X-RazorGate-Vade: gggruggvucftvghtrhhoucdtuddrgedvgedrudejgdegudcutefuodetggdotefrodftvfcurfhrohhfihhlvgemuceutffkvffkuffjvffgnffgvefqofdpqfgfvfenuceurghilhhouhhtmecufedtudenucesvcftvggtihhpihgvnhhtshculddquddttddmnecujfgurhepkfffgggfuffvfhfhjggtgfesthejredttdefjeenucfhrhhomheplfhonhcuvfhurhhnvgihuceojhhonhdrthhurhhnvgihsegurhhonhgvtghouggvrdhorhhgrdhukheqnecuggftrfgrthhtvghrnhepffekiefgudejheetudeigfejledtleegleetkeduteeftdfffefhueefgfeutedtnecukfhppeekuddrudehfedrleekrddvtdeinecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehhvghloheplgduledvrdduieekrddurddutdeingdpihhnvghtpeekuddrudehfedrleekrddvtdeipdhmrghilhhfrhhomhepjhhonhdrthhurhhnvgihsegurhhonhgvtghouggvrdhorhhgrdhukhdpnhgspghrtghpthhtohepvddprhgtphhtthhopegthihgfihinhestgihghifihhnrdgtohhmpdhrtghpthhtohepuggrvhhiugesthgrrhhiuggvshdrtghomh X-RazorGate-Vade-Verdict: clean 0 X-RazorGate-Vade-Classification: clean Received: from [192.168.1.106] (81.153.98.206) by sa-prd-rgout-005.btmx-prd.synchronoss.net (5.8.716.04) (authenticated as jonturney@btinternet.com) id 6139452E416C4E7E; Wed, 2 Nov 2022 12:38:09 +0000 Message-ID: <20435aae-2753-d49f-2de6-94a4ac624813@dronecode.org.uk> Date: Wed, 2 Nov 2022 12:38:06 +0000 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:102.0) Gecko/20100101 Thunderbird/102.4.1 Subject: Re: Debugging malloc crash in gdb Content-Language: en-GB To: David Allsopp , The Cygwin Mailing List References: <000001d8e2dd$51be37a0$f53aa6e0$@cl.cam.ac.uk> From: Jon Turney In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-3568.7 required=5.0 tests=BAYES_00,FORGED_SPF_HELO,KAM_DMARC_STATUS,KAM_LAZY_DOMAIN_SECURITY,NICE_REPLY_A,RCVD_IN_BARRACUDACENTRAL,RCVD_IN_DNSWL_NONE,SPF_HELO_PASS,SPF_NONE,TXREP autolearn=no 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 20/10/2022 09:22, David Allsopp wrote: > On Tue, 18 Oct 2022 at 20:09, Jon Turney wrote: >> On 18/10/2022 11:35, David Allsopp wrote: >>> I'm wondering if I may be able to have some pointers for debugging what >>> seems to be an unexpected interaction between mmap/mprotect/munmap and >>> malloc with the OCaml runtime. [...]>>> /cygdrive/d/a/scallywag/gdb/gdb-11.2-1.x86_64/src/gdb-11.2/gdb/infrun.c:2550 >>> : internal-error: void resume_1(gdb_signal): Assertion >>> `pc_in_thread_step_range (pc, tp)' failed. > > I'm not sure now which combination of stepping directly into the > malloc call, adding set cygwin-exceptions on or switching to gdb 12.1, > but either way I was able to get to an invalid memory access in > mmap_alloc in malloc.cc. At this point, p was a pointer to the start > of the 256M block which had been passed to munmap. > > What I then noticed from that is a bug in our code - the mmap'd region > was actually 256M+64K but the size passed to munmap was 256M... so the > munmap call was not releasing the entire block. Fixing that on the > OCaml side fixes the error completely - I don't know whether what we > were seeing before counts as a bug in Cygwin's allocator? That depends. Is the ocaml code relying on undefined behaviour, which just happens to work elsewhere, but fails on cygwin? Or is it defined behaviour, which Cygwin doesn't implement correctly? (It's not unreasonable that Cygwin's memory allocator is more sensitive to some classes of errors than other implementations)