delorie.com/archives/browse.cgi   search  
Mail Archives: djgpp/2019/06/17/01:18:53

X-Authentication-Warning: delorie.com: mail set sender to djgpp-bounces using -f
From: Rod Pemberton <invalid AT lkntrgzxc DOT com>
Newsgroups: comp.os.msdos.djgpp
Subject: Re: malloc() returns pointer to already allocated memory
Date: Mon, 17 Jun 2019 01:05:38 -0400
Organization: Aioe.org NNTP Server
Lines: 58
Message-ID: <qe76u1$1kj8$1@gioia.aioe.org>
References: <158e5d20-0a90-4beb-de48-da328379d8fb AT gmail DOT com>
NNTP-Posting-Host: +15yR2JuBIwiofOqK4kSZw.user.gioia.aioe.org
Mime-Version: 1.0
X-Complaints-To: abuse AT aioe DOT org
X-Notice: Filtered by postfilter v. 0.9.2
Bytes: 3577
To: djgpp AT delorie DOT com
DJ-Gateway: from newsgroup comp.os.msdos.djgpp
Reply-To: djgpp AT delorie DOT com

On Mon, 17 Jun 2019 02:27:18 +0200
"J.W. Jagersma (jwjagersma AT gmail DOT com) [via djgpp AT delorie DOT com]"
<djgpp AT delorie DOT com> wrote:

> I ran into this issue with malloc(). It seems that, given enough 
> allocations, malloc() will eventually return a pointer into already 
> allocated memory.
> 
> The attached program is able to reproduce this rather consistently,
> but only under cwsdpmi. It also only happens if the memory has
> previously been written to (suggesting a paging issue?). However the
> code that first led me to investigate this also exhibits the same
> problem under hdpmi. As such, I'm still not entirely convinced that
> this initial issue wasn't caused by my own code. I also find it hard
> to believe that no one else noticed this rather obvious problem
> before me. Still, the attached program demonstrates this clobbering
> issue, and I think this would warrant further investigation.
> 
> Any insight is much appreciated.
> 

First problem is trivial.  The code doesn't compile with older DJGPP
v1.3.  The declaration of 'i' within the for() loop errors, but other
C99 declarations only warn.

Second problem is you don't call memset() prior to using memory, nor
free() after you're done using it.  Of course, calling memset() would
prevent your method of "clobber" detection from working.  But, not
calling memset() means you don't know if the magic clobber value is:
a) from you setting it within your program, or
b) from some random garbage values in memory.

Third problem is you apparently didn't test the program without the
"p[i] = magic;" line.  If you had, you would've noticed that your
program clobbers even without setting memory to magic values. In
other words, memory is filled with random values, since it wasn't
cleared by memset().  Also, some of those random values happen to
match your program's random magic value used to detect clobbered memory.

Fourth problem is that you can't actually confirm if memory is being
clobbered from within a C program for two reasons: inability to
distinguish a magic value from an identical random value in memory
which hasn't been cleared, and the inability in C to allocate, clear,
and free memory, prior to the re-use of the exact same memory for a
clobber test.  To test this issue properly requires a modified version
of the memory allocator, i.e., CWSDPMI in this case.

Finally, you didn't report which version of DJGPP, or CWSDPMI, and
whether or not your code is operating in a Windows 98/SE/ME/XP etc
console.  When operating in a Windows console, CWSDPMI is not being
used.  The Windows DPMI host is being used.


Rod Pemberton
-- 
Once upon a time, many decades ago in a place far away, humble people
sought their freedom, and lost. "Ideas are bulletproof."

- Raw text -


  webmaster     delorie software   privacy  
  Copyright © 2019   by DJ Delorie     Updated Jul 2019