DMARC-Filter:	OpenDMARC Filter v1.4.2 delorie.com 683F7ml52334686
Authentication-Results:	delorie.com; dmarc=none (p=none dis=none) header.from=delorie.com
Authentication-Results:	delorie.com; spf=pass smtp.mailfrom=delorie.com
X-Authentication-Warning:	delorie.com: mail set sender to djgpp-workers-bounces using -f
DMARC-Filter:	OpenDMARC Filter v1.4.2 delorie.com 683F7mCD2334664
Authentication-Results:	delorie.com; dmarc=pass (p=none dis=none) header.from=gmail.com
Authentication-Results:	delorie.com; spf=pass smtp.mailfrom=gmail.com
DKIM-Filter:	OpenDKIM Filter v2.11.0 delorie.com 683F7mCD2334664
Authentication-Results:	delorie.com;
	dkim=pass (2048-bit key, unprotected) header.d=gmail.com header.i=@gmail.com header.a=rsa-sha256 header.s=20251104 header.b=kL3BTmUf
X-Recipient:	djgpp-workers AT delorie DOT com
X-Original-DKIM-Signature:	v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=gmail.com; s=20251104; t=1788448067; x=1789052867; darn=delorie.com;
	h=content-transfer-encoding:content-type:subject:from
	:content-language:to:user-agent:mime-version:date:message-id:from:to
	:cc:subject:date:message-id:reply-to:content-type;
	bh=AGBflRgAkmiNzqXwhtsb1e87eXBAo5UylB5eQYN/QtY=;
	b=kL3BTmUfjeOmjRdAltG+yv8St2OxK13jffPCDKMXL7X3TGJGUakeNy41Le5wzDPFio
	phYRWGmxgil7Xrmf2rk25ex6YT9u8nTZrUHvdDpfcOpXVIFhtVCbE2RmKtPa6aJxURy3
	44DwN2ar/TKmayc7ahX0xj35DJfuwIOjXDL7NAKW/ZcyUgi+61Tf0IBV73QIfMwM9EkT
	ClOvHhik5jPmCoOIHXdgYxA/bWznG5t7X/IYsuC11Zk4iKBEp1joDxdwnXu6xEiGkt/Z
	QsYgTbdTqu117nLM2h5dAt1CKI4jxZwpuupo2tI9y2WfHZ+9J5BUDoA+MfnUW/97bKc5
	LnCg==
X-Google-DKIM-Signature:	v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20251104; t=1788448067; x=1789052867;
	h=content-transfer-encoding:content-type:subject:from
	:content-language:to:user-agent:mime-version:date:message-id:x-gm-gg
	:x-gm-message-state:from:to:cc:subject:date:message-id:reply-to
	:content-type;
	bh=AGBflRgAkmiNzqXwhtsb1e87eXBAo5UylB5eQYN/QtY=;
	b=iC8zudY7w3Rl8kqoG9ApnHDqeXuf3bWeHQ7Zsow7Y5dQvSoP9/VrIpbZ4N8179mjqI
	4T48nCcFr4ojA3XSNF4EV2GxUw/107qPT+ilPsZtfuXROdh89Rgvdedlq9e6tUw/BPo3
	Lq+ZrxEHiRecVo5EBPlMrE8okRCi2jR/dbHAnKCUrWCLszJWI7Dmip1lDcV4bdBeBVCk
	Zwzr4XIWqZ0nynFYFW9fEU966rV/zCZ80GE7aV6eQdbt1Gj4E4mEZSDORAuOGxHIBpGL
	oB0e447lMJxvRJT/NvL0o+hElzqgki7WvCMtY/OQ0DGHR/JmfQIGYBXXNfW5k/N2RPMd
	KgPw==
X-Gm-Message-State:	AFuF++l1DAGE55ngXPgc7k0ovfK/edTYpsvaYoDkz5v6keohjM6hk6Jq
	yBGA00Py6XHAYiBiozob8dVX7fGB+W2YcW81mmz4UE3CIYFEpQtcSfyrB8vlpNgM
X-Gm-Gg:	AYBFou1hFKwv84eJE1o+l8B7I0MrvUvnzBoS0uHFJvAVexlkNJlc1z6J9zn6uEVNYO9
	oUhdHI04qgpQPGhBPekVFmBhOjsDB7GO3rEYvLz3GPtMy2vCcTqi4fLliFRxOcUuo3tE9TribEx
	lLWxJslNwTxn46D/ew+Vlg5xZuSx+ie1EwGKowm2iQGL0Fd/c4padhJxRw7AxY3QuL1REAak02a
	B+tlFls25XBSCgn3uZR64Pq0PAaXW8IMZpb1jTu1+vyN8r+SBveuHoXM5YqV5pKYWMSzYjozqBm
	+FSDlaE1ftPJsItR093fL/ODZrDHTaVzxzz4Oly7Zldg3ajQ/BinbylizDeAuV5zelu5nMVuhfA
	JC/MNRJyIm9lIXRKapTFtPio/mrACokjFDOyeWfXIzCBq80EmNiHXV09zh55HE4Sft35HVdsfnQ
	M5vYLMLRgnbcHusKfNVvmArShJ8SpzIe4bN3GTmhvwNd9prkdyQOz19qZsw6dyAjm5XBPzanCyZ
	o8+Hm+mPIp8kD56gSjAs2CKDRR/u6hxuKFcRtaeFEKSVHz8m0Ge
X-Received:	by 2002:a05:620a:4399:b0:939:b99:eec5 with SMTP id af79cd13be357-9397ebd2ef0mr29670785a.1.1788448061953;
	Thu, 03 Sep 2026 08:07:41 -0700 (PDT)
Message-ID:	<ea4e57b0-05ca-42cf-9112-47783ee8d73f@gmail.com>
Date:	Thu, 3 Sep 2026 11:07:40 -0400
MIME-Version:	1.0
User-Agent:	Mozilla Thunderbird
To:	djgpp-workers AT delorie DOT com
From:	"Frank Sapone (emoaddict15 AT gmail DOT com) [via djgpp-workers AT delorie DOT com]" <djgpp-workers AT delorie DOT com>
Subject:	Re: memalign broken (again)
Reply-To:	djgpp-workers AT delorie DOT com

> On Wed, Nov 21, 2018 at 4:33 AM Ozkan Sezer (sezeroz AT gmail DOT com) [via
> djgpp-workers AT delorie DOT com] <djgpp-workers AT delorie DOT com> wrote:
> > > On 11/21/18, Peter Ross <pross AT xvid DOT org> wrote: > > hi, > > 
> > > djgpp memalign still fails when: > > > > 1. alignment is >= 16 
> bytes > > 2. some sequence of memory allocations have already occured. 
> > > > > the test case below is reproducible with djgpp cvs and 
> 2.05+nmemalign.patch > > (patch was found here: > > 
> https://aur.archlinux.org/cgit/aur.git/tree/nmemalign.patch?h=dosbox-djcrx) 
> > > > > tested using freedos 1.2 on physical hardware. > > > > --- > > 
> #include <stdio.h> > > #include <malloc.h> > > > > #define 
> TEST(alignment, size) \ > > printf("memalign(%d,%d)=", alignment, 
> size); \ > > ptr = memalign(alignment, size); \ > > printf("%p\n", 
> ptr); > > > > int main() > > { > > void * ptr; > > TEST(1, 46) > > 
> TEST(4, 583) > > TEST(64, 773) > > TEST(32, 889) /* <-- reliably fails 
> here */ > > return 0; > > } > > Did a quick build & run, reproduces 
> under dosemu and dosbox, too.
> Apologies for reviving an old thread, but I think I found the root
> cause of this bug.
>
> The problem is in the branch where the allocated block is not
> pre-aligned to the desired alignment, which means the block needs to
> be split into two parts and the first one freed. The size passed to
> __nmalloc_split(), which is supposed to include the space for the
> memblock header plus the allocated data region, is calculated as
> `alignment - misalign`, which is always too small. For example, if the
> requested alignment is 16 bytes, the calculated size for the split
> will be 15 bytes, which is too small to contain a memblock structure
> (20+ bytes). This will result in a corrupted free list when the
> newly-created memblock is written on top of part of the original one.
> The size passed to nmalloc() includes extra space (3 * ALIGN in the
> XTRA definition) to ensure that there is room to insert another
> memblock header, but the split calculation never uses it.
>
> One possible fix (patch below) is to calculate the region to be
> returned by adding XTRA (which includes the alignment plus the minimal
> space needed for a new memblock), adjusting the resulting pointer down
> so that it will be a multiple of the requested alignment (this will
> always be within the bounds of the allocation due to the XTRA
> addition), then using the MEMBLKp macro to calculate the appropriate
> position for the new memblock to be created by the split, and finally
> using the difference between the original and aligned memblocks as the
> size for the __nmalloc_split() call. This ensures that the returned
> pointer is always actually aligned to the requested value, which I
> don't think the old code would have done even assuming it did not
> corrupt the free list - the `misalign` calculation is based on the
> original data location, but the split would adjust this pointer by
> DATAOFFSET when adding the new memblock, so the resulting split block
> would have always been misaligned.
>
> ---
>   src/libc/ansi/stdlib/nmalign.c | 9 ++++++---
>   1 file changed, 6 insertions(+), 3 deletions(-)
>
> diff --git a/src/libc/ansi/stdlib/nmalign.c b/src/libc/ansi/stdlib/nmalign.c
> index 541d1a8b..90ee4c4b 100644
> --- a/src/libc/ansi/stdlib/nmalign.c
> +++ b/src/libc/ansi/stdlib/nmalign.c
> @@ -110,8 +110,9 @@ static inline int invalid(size_t alignment)
>
>   void *nmemalign(size_t alignment, size_t size)
>   {
> -   memblockp m = NULL;
> -   void     *minit;
> +   memblockp m = NULL, m1;
> +   char     *minit;
> +   char     *malign;
>      ulong     misalign;
>      size_t    szneed, sz = size; /* preserve arg for hooks */
>
> @@ -141,7 +142,9 @@ void *nmemalign(size_t alignment, size_t size)
>               /* two or more chunks to release */
>               DBGPRTM("  Complex case, release multiple chunks");
>               DBGEOLN;
> -            nfree(PTR(__nmalloc_split(&m, alignment - misalign)));
> +            malign = (char *)(((ulong)minit + XTRA - 1) & ~(alignment - 1));
> +            m1 = MEMBLKp(malign);
> +            nfree(PTR(__nmalloc_split(&m, (ulong)m1 - (ulong)m)));
>               return nrealloc(PTR(m), size);
>            }
>         } /* alignment > ALIGN */
Bringing this up again.  I have had a small handful of complaints about 
combinelo: memory fouled on some machines for my Quake DOS port.  This 
was never tested and vetted, but the patch looks and sounds reasonable.  
Can we get it merged?

Frank

- Raw text -