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>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Content-Language: en-US
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
Precedence: bulk


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