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 21:08:56 GMT
Btw., I made some changes to the test and committed them here:
   http://svn.apache.org/viewvc?rev=426672&view=rev
You might want to test them out to see if it helps.

Martin

Nicole Willson wrote:
> 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