stdcxx-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Martin Sebor <se...@roguewave.com>
Subject Re: problem in temp_buffer
Date Fri, 28 Jul 2006 18:25:55 GMT
Nicole Willson wrote:
> No, I'm doing a 32 bit build on a 64bit platform 

Okay, so PTRDIFF_MAX is 0x7fffffff and SIZE_MAX, the size of the
largest object, is 0xffffffffU (i.e., 4GB). But in that case I
don't understand how you could have changed the test to allocate
FFFFFFFFFFFFFFFF bytes.

Martin

> 
> -----Original Message-----
> From: Martin Sebor [mailto:sebor@roguewave.com] 
> Sent: Friday, July 28, 2006 12:05 PM
> To: stdcxx-dev@incubator.apache.org
> Subject: Re: problem in temp_buffer
> 
> Nicole Willson wrote:
> 
>>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?
> 
> 
> I'm not sure I see the relevance of PTRDIFF_MAX but the macro should
> expand to the largest value representable in an object of type
> ptrdiff_t, which is a signed integer type capable of representing the
> difference between any two pointers. It will usually be the same as
> LONG_MAX, i.e., 0x7fffffff on 32-bit platforms and 0x7fffffffffffffff on
> 64-bit platforms.
> 
> Btw., if you are doing a 64-bit build the addresses below (in the gdb
> output) don't look quite correct.
> 
> Martin
> 
> 
>>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