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