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:[EMAIL PROTECTED] Sent: Friday, July 28, 2006 12:26 PM To: [email protected] 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:[EMAIL PROTECTED] > Sent: Friday, July 28, 2006 12:05 PM > To: [email protected] > 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:[EMAIL PROTECTED] >>Sent: Thursday, July 27, 2006 11:50 AM >>To: [email protected] >>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 > > >
