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 20:47:36 GMT
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.

I'm having trouble building the 32-bit archive with this darn
compiler. What does your command line look like?

Here's mine (with the errors on the bottom):

...
xlc -c -I/amd/devco/sebor/dev/stdlib/include/ansi -D_RWSTDDEBUG 
-D_RWSTD_USE_CONFIG -I/amd/devco/sebor/dev/stdlib/include 
-I/build/sebor/xlc-8.0-11s/include 
-F/package/1/ppc64/compilers/ibm/va80/vac.cfg -g 
-qtemplateregistry=repository.ti 
/amd/devco/sebor/dev/stdlib/src/wctype.cpp
gencat rwstderr.cat /amd/devco/sebor/dev/stdlib/src/rwstderr.msg
xlc -I/amd/devco/sebor/dev/stdlib/include/ansi -D_RWSTDDEBUG 
-D_RWSTD_USE_CONFIG -I/amd/devco/sebor/dev/stdlib/include 
-I/build/sebor/xlc-8.0-11s/include 
-F/package/1/ppc64/compilers/ibm/va80/vac.cfg 
-I/amd/devco/sebor/dev/stdlib/include/ansi -D_RWSTDDEBUG 
-D_RWSTD_USE_CONFIG   -qtemplateregistry=repository.ti     -qmkshrobj 
assert.o atomic.o bitset.o catalog.o codecvt.o collate.o ctype.o 
ctype_bits.o exception.o export.o facet.o file.o instance.o ios.o 
ios_bits.o iostore.o iostream.o iso2022.o limits.o limits_bits.o 
locale_bits.o locale_body.o locale_classic.o locale_combine.o 
locale_core.o locale_eq.o locale_global.o locale_name.o memattr.o 
memory.o messages.o num_get.o num_put.o punct.o random.o setlocale.o 
string.o strstream.o strtol.o ti_collate.o ti_filebuf.o ti_insert_dbl.o 
ti_insert_int.o ti_insert_ptr.o ti_ios.o ti_istream.o ti_messages.o 
ti_money_get.o ti_money_put.o ti_moneypunct.o ti_num_get.o ti_num_put.o 
ti_numpunct.o ti_ostream.o ti_streambuf.o ti_string.o ti_stringbuf.o 
ti_time_get.o ti_time_put.o ti_wcollate.o ti_wfilebuf.o ti_winsert_dbl.o 
ti_winsert_int.o ti_winsert_ptr.o ti_wios.o ti_wistream.o ti_wmessages.o 
ti_wmoney_get.o ti_wmoney_put.o ti_wmoneypunct.o ti_wnum_get.o 
ti_wnum_put.o ti_wnumpunct.o ti_wostream.o ti_wstreambuf.o ti_wstring.o 
ti_wstringbuf.o ti_wtime_get.o ti_wtime_put.o time_get.o time_put.o 
tmpbuf.o typeinfo.o valarray.o vecbool.o version.o wcodecvt.o wctype.o
/usr/bin/ld: Error: The symbol `backtrace@@GLIBC_2.1' has a R_PPC_REL24 
relocation, that means 'assert.o' was compiled without -fPIC.
/usr/bin/ld: Error: The symbol `backtrace_symbols_fd@@GLIBC_2.1' has a 
R_PPC_REL24 relocation, that means 'assert.o' was compiled without -fPIC.
/usr/bin/ld: Error: The symbol `fprintf@@GLIBC_2.0' has a R_PPC_REL24 
relocation, that means 'assert.o' was compiled without -fPIC.
/usr/bin/ld: Error: The symbol `fprintf@@GLIBC_2.0' has a R_PPC_REL24 
relocation, that means 'assert.o' was compiled without -fPIC.
/usr/bin/ld: Error: The symbol `abort@@GLIBC_2.0' has a R_PPC_REL24 
relocation, that means 'assert.o' was compiled without -fPIC.
make: *** [/build/sebor/xlc-8.0-11s/lib/libstd11s.a] Error 1
make: Leaving directory `/build/sebor/xlc-8.0-11s/lib'


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