X-Authentication-Warning: delorie.com: mail set sender to djgpp-bounces using -f
X-Recipient: djgpp AT delorie DOT com
Date: Mon, 17 Jun 2019 20:08:53 +0300
Message-Id: <83imt4t9zu.fsf@gnu.org>
From: "Eli Zaretskii (eliz AT gnu DOT org) [via djgpp AT delorie DOT com]" <djgpp AT delorie DOT com>
To: djgpp AT delorie DOT com
In-reply-to: <12f60f52-addf-939d-8eee-e8f67a95715c@gmail.com>
	(djgpp AT delorie DOT com)
Subject: Re: malloc() returns pointer to already allocated memory
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>
X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic]
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

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