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 19:24:59 GMT
I changed numelems from _RWSTD_PTRDIFF_MAX to  0xffffffffffffffffULL.  I
can't find any instance of deallocation that looks bad.   Basically, the
malloc fails (as it should) the first time it is called with
_RWSTD_PTRDIFF_MAX / sizeof(type) nelems when the element is an 8byte
type, but not the second time.  I'm going to work on a different problem
for a while because this one is driving me nuts.  If you have time and
want to take a run at it, it only occurs in 8s and 11s 32 bit builds on
the 64 bit Power5 platform.

-----Original Message-----
From: Martin Sebor [mailto:sebor@roguewave.com] 
Sent: Friday, July 28, 2006 12:26 PM
To: stdcxx-dev@incubator.apache.org
Subject: Re: problem in temp_buffer

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