X-Authentication-Warning:	delorie.com: mail set sender to djgpp-bounces using -f
X-Recipient:	djgpp AT delorie DOT com
X-Original-DKIM-Signature:	v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=gmail.com; s=20161025;
	h=subject:to:references:from:message-id:date:user-agent:mime-version
	:in-reply-to:content-transfer-encoding:content-language;
	bh=6gFsomSLXIX2u+6itgrRNYDpBmZK+1R7FNdjoH6rn+U=;
	b=BXLuKjjgrh/V9HrGhXiZvS3vCzP4FdcfpB9rQBJ4uCIX3n5K+8/kGkoi2k3RS/ELpz
	5/U/2myhKDfrotpl9Y3aSX2PBsXkKkcuV6kjzDwrIuHgz9N2YkcUpsC62NG2TJmstao8
	miWQ9E6zidbTn7sQv/S5Tto7KeCT3bNebOoxiKJgZ3oKsU/mHsXnXbGx62s0Q0IDxrzN
	xN1H+XFFtOraSgIqRWXsG9wAaYnxH9K8eQWkHxtEARfG1cCEEHYwn+Ff0Z4qAljG7Vzo
	cWMxbirtasa+xXmiEqXWnc6i5Y/ZyQhx1OQVs1MoxxSN5NAulozBdige4JhJRM5nDraH
	n0TQ==
X-Google-DKIM-Signature:	v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20161025;
	h=x-gm-message-state:subject:to:references:from:message-id:date
	:user-agent:mime-version:in-reply-to:content-transfer-encoding
	:content-language;
	bh=6gFsomSLXIX2u+6itgrRNYDpBmZK+1R7FNdjoH6rn+U=;
	b=G/pvk6+VJJbmrAro4ysKbNc+85SkecOzcNIuPIKt5lfaUXty094IUgpygbBlsN8dXl
	AQ/ThZUZU7ai9nE7Zs4ZU39Y+Dd/z0BvMku16mQcY/d3iyRnDzeQ9b57lCbn5TVsbKCi
	xp7kdr2c4NgboJnVsqmIFU+wowHldFlqQQ018H1KMwy/yL/OsO32WNIIbLGB3o7nDXAg
	xjfxIjVwUHPobrrJbqRAWU42VtmQaV+3FsRA9TFpS5Yq6DQOCEtff4lTb171hUvYyZ1f
	3yVPecYw6VYLdV8uekkZ4XsZfMdo0bzm5Vwny56qxHvRbNZN+202M/mOhxi2keuoSvnk
	Iqyg==
X-Gm-Message-State:	APjAAAXKsh0nQWLcXp54vaUv/tmsbpBbFFPd6vpHdFL4qnXmJHni1dlg
	up7Ybm6v2y9FFc4aNBVqEBPxixqL
X-Google-Smtp-Source:	APXvYqxgQtmob18uKgG7n7pG47AVjxKXQ/ly1SZHmDIY1jnZoDh1DWB1EbKtAxKCto2ISaEIb7uENQ==
X-Received:	by 2002:a62:2c8e:: with SMTP id s136mr70898086pfs.3.1560793293778;
	Mon, 17 Jun 2019 10:41:33 -0700 (PDT)
Subject:	Re: malloc() returns pointer to already allocated memory
To:	djgpp AT delorie DOT com
References:	<158e5d20-0a90-4beb-de48-da328379d8fb AT gmail DOT com>
	<qe76u1$1kj8$1 AT gioia DOT aioe DOT org> <83tvcoth73 DOT fsf AT gnu DOT org>
	<12f60f52-addf-939d-8eee-e8f67a95715c AT gmail DOT com> <83imt4t9zu DOT fsf AT gnu DOT org>
From:	"Frank Sapone (emoaddict15 AT gmail DOT com) [via djgpp AT delorie DOT com]" <djgpp AT delorie DOT com>
Message-ID:	<7051bd78-dc41-0eb2-1657-1a8dbfd479ee@gmail.com>
Date:	Mon, 17 Jun 2019 13:41:29 -0400
User-Agent:	Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101
	Thunderbird/60.7.1
MIME-Version:	1.0
In-Reply-To:	<83imt4t9zu.fsf@gnu.org>
Reply-To:	djgpp AT delorie DOT com
Errors-To:	nobody AT delorie DOT com
X-Mailing-List:	djgpp AT delorie DOT com
X-Unsubscribes-To:	listserv AT delorie DOT com

On 6/17/2019 1:08 PM, Eli Zaretskii (eliz AT gnu DOT org) [via 
djgpp AT delorie DOT com] wrote:
>> From: "J.W. Jagersma (jwjagersma AT gmail DOT com) [via djgpp AT delorie DOT com]" <djgpp AT delorie DOT com>
>> Date: Mon, 17 Jun 2019 18:46:24 +0200
>>
>>> Right.  There's a startup flag that a program could optionally set to
>>> request that allocated memory be filled with a specific fixed value,
>>> then tests for clobbering could work.  See the documentation of
>>> _crt0_startup_flags in the libc manual.
>>>
>> If the issue is caused by the dpmi host or sbrk(), then I think enabling
>> the _CRT0_FLAG_FILL_SBRK_MEMORY flag would mask this bug.
> How can it?  sbrk cannot possibly cause this because your program
> doesn't sound like one that would ever release sbrk'ed memory back to
> the DPMI host.  And malloc just fills the buffer it hands to you,
> there's no effect of this flag on the address of that buffer.
>
>> With this flag enabled, the test does complete successfully on
>> cwsdpmi.
> Which probably means your detection of "already allocated" is flawed
> in some sense.  All this flag does is wipe out any possible garbage in
> the memory you get from malloc, left-overs from previous allocations;
> the flag AFAIR has no other effects on the algorithms of malloc.
>
> In general, at thus point in DJGPP's life cycle, I'd be hard-pressed
> to believe we have such blatant bugs in memory allocation.  I used to
> run Emacs compiled with DJGPP for days on end without any memory
> problems.  Emacs is very memory-intensive program, so the DJGPP v2
> libc gets a clean bill of health from me, as far as memory allocation
> is concerned.  It's always possible some bug has crept into the
> library, but I'd suspect the application first and foremost.

I can say from the extended Quake 1 and 2 ports that I maintain they run 
well and they can run the very large maps that require 256MB+ of RAM and 
have not ran into problems there either.

Frank

- Raw text -