incubator-stdcxx-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Nicole Willson" <will...@roguewave.com>
Subject RE: problem in temp_buffer
Date Fri, 28 Jul 2006 15:36:39 GMT
Ok, when I changed the test to allocate a significantly larger chunk of
memory (18,446,744,073,709,551,615, the equivalent of FFFFFFFFFFFFFFFF
(8bytes)), it finally failed to allocate and returned a 0 as expected.
So the question becomes, is the value of _RWSTD_PTRDIFF_MAX incorrect
for this platform, or is it just that there is another problem that gets
covered up by having the memory so large?

Nicole

-----Original Message-----
From: Martin Sebor [mailto:sebor@roguewave.com] 
Sent: Thursday, July 27, 2006 11:50 AM
To: stdcxx-dev@incubator.apache.org
Subject: Re: problem in temp_buffer

Nicole Willson wrote:
> The problem is simply that the address for last is:
> (gdb) print last
> $5 = (Header *) 0x77f00008
> And the address for ptr (after malloc) is:
> (gdb) print ptr
> $4 = (void *) 0x77e00d30
> 
> Since ptr is
> (gdb) print block_size
> $1 = 2147483680
> 
> The end of the block pointed to by ptr is 0xf7e00d50 - you will note 
> that last is inside of ptr's block of memory now.  Then when memset is

> called on ptr setting everything to -1, last's information is 
> obliterated.
> 
> My question now is:
> Since last is in the midst of the block allocated to ptr, shouldn't 
> that allocation have failed?

The allocation should fail if the size of the requested block (nbytes)
is greater than malloc() can find. If it fails, the returned pointer
will be 0. Otherwise the allocated block must not overlap with any other
previously allocated (and not yet deallocated) block. From what you said
it sounds like last might be pointing to an already deallocated block of
memory (which should not happen). If that's what's happening you'll need
to figure out why :)

Martin

Mime
View raw message