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
>
>
>
|