You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@stdcxx.apache.org by Eric Lemings <Er...@roguewave.com> on 2008/03/21 21:35:36 UTC
[STDCXX-709] ContainerData ctor and UserClass::from_char()
So I'm stepping through the ContainerTestCaseData (const ContainerFunc
&func, const ContainerTestCase &tcase) constructor as shown in the
following stack frame:
(gdb) where
#0 ContainerTestCaseData<UserClass>::ContainerTestCaseData
(this=0x7fffe750,
func=@0x7fffe830, tcase=@0x4095ba0)
at
/amd/devco/lemings/work/stdcxx/trunk.gofish/tests/include/23.containers.
h:280
Here's part of the ctor:
(gdb) list
276 char buf [256];
277
278 strlen_ = sizeof (buf);
279 char* str = rw_expand (buf, tcase.str, tcase.str_len,
&strlen_);
280 str_ = T::from_char (str, strlen_);
281 if (str != buf)
282 delete[] str;
Notice anything unusual around line 280? Here's a hint:
tests/include/rw_value.h:
228 // construct an array of objects of type UserClass each
initialized
229 // from the corresponding element of the character array
230 // when the last argument is true and the character array
231 // is not sorted in ascending order the function fails by
232 // returning 0
233 static UserClass*
234 from_char (const char*, _RWSTD_SIZE_T = _RWSTD_SIZE_MAX,
235 bool = false);
Now I'm sorta new to this UserClass and container testing but but WTF is
going on here? char* and UserClass* are convertible certainly but
clearly not compatible.
Brad.
Re: [STDCXX-709] ContainerData ctor and UserClass::from_char()
Posted by Martin Sebor <se...@roguewave.com>.
Incidentally, there is a script that compares two or more config
headers. I don't see it in Subversion so it must not have been
migrated from Perforce yet:
//stdlib/dev/etc/stdlib/scripts/cfgcmp
We might want to dust it off at some point in the future and start
using it. It can be quite handy when porting to new versions of
compilers or compilers on new platforms.
Martin
Martin Sebor wrote:
> The two versions of aCC are very different (based on a different
> C++ front ends). Each also runs on a different OS and hardware.
> I think significant differences are to be expected. That doesn't
> mean that there isn't a problem in our aCC 6.16 configuration,
> but neither does it imply there is one.
>
> Eric Lemings wrote:
>>
>> In regards to STDCXX-709, note that there are no config differences
>> in the delete operators, only the new operators.
>
> These should be benign and unrelated to STDCXX-709.
>
> FWIW, if you still suspect a mismatch between the allocation and
> deallocation functions called from the tests I would suggest to
> try to create a small test case reproducing it. I.e., create an
> archive lib that allocates memory using the new expression and
> a program that replaces operators new and delete, links with the
> library and attempts to deallocate the memory allocated by the
> library. See if the right operators are being called.
>
> Martin
>
>>
>> Brad.
>>
>>> -----Original Message-----
>>> From: Eric Lemings [mailto:Eric.Lemings@roguewave.com] Sent: Monday,
>>> March 24, 2008 3:21 PM
>>> To: dev@stdcxx.apache.org
>>> Subject: RE: [STDCXX-709] ContainerData ctor and UserClass::from_char()
>>>
>>>
>>> I was just comparing the configuration differences for these
>>> two platforms:
>>>
>>> HP-UX B.11.21/HP aCC 3.73
>>> HP-UX B.11.31/HP aCC 6.16
>>>
>>> See http://people.apache.org/~elemings/diff.out.
>>>
>>> There seems to be way to many configuation differences. I think
>>> we may have a much more serious problem on HP-UX ia64.
>>>
>>> Brad.
>>>
>>>> -----Original Message-----
>>>> From: Martin Sebor [mailto:msebor@gmail.com] On Behalf Of
>>> Martin Sebor
>>>> Sent: Friday, March 21, 2008 5:10 PM
>>>> To: dev@stdcxx.apache.org
>>>> Subject: Re: [STDCXX-709] ContainerData ctor and UserClass::from_char()
>>>>
>>>> Eric Lemings wrote:
>>>>>
>>>>>
>>>>>> -----Original Message-----
>>>>>> From: Martin Sebor [mailto:sebor@roguewave.com] Sent: Friday,
>>>>>> March 21, 2008 3:32 PM
>>>>>> To: dev@stdcxx.apache.org
>>>>>> Subject: Re: [STDCXX-709] ContainerData ctor and
>>>>>> UserClass::from_char()
>>>>>>
>>>>> ...
>>>>>> So you think there's a mismatch between the allocation function
>>>>>> invoked in value.cpp and the deallocation function called in the
>>>>>> header? Why would that be? IIUC, tests that replace operator new
>>>>>> and operator delete (such as 23.list.assign) replace it for the
>>>>>> whole process. If there's a mismatch, it can only be because
>>>>>> the operators aren't replaced consistently. Making sure this
>>>>>> replacement happens across the whole process, including any
>>>>>> libraries, is the responsibility of the C++ runtime (i.e.,
>>>>>> the compiler). If your analysis is correct, the C++ runtime
>>>>>> on IPF would have to be buggy.
>>>>>>
>>>>>> Or did I misunderstand what you were trying to say?
>>>>> Sounds about right.
>>>>>
>>>>> I just noticed there's a runtime link error in the config test
>>>>> OPERATOR_NEW_ARRAY_PLACEMENT on HP-UX IPF platforms. May be the
>>>>> culprit.
>>>>>
>>>>> [user@host]$ ./include/OPERATOR_NEW_ARRAY_PLACEMENT
>>>>> /usr/lib/hpux32/dld.so: Unsatisfied code symbol '_ZnamPv' in load
>>>>> module './stdcxx/include/OPERATOR_NEW_ARRAY_PLACEMENT'.
>>>>> Killed
>>>> That's a check for placement new in the runtime library. I don't
>>>> think that has any bearing on the replaceability of operator new.
>>>>
>>>> I.e., the first one is not replaceable:
>>>>
>>>> void* operator new(size_t, void*) throw();
>>>> void* operator new[](size_t, void*) throw();
>>>>
>>>> while the second one is:
>>>>
>>>> void* operator(size_t) throw (bad_alloc);
>>>> void* operator[](size_t) throw (bad_alloc);
>>>>
>>>> The first form is usually defined inline in <new>, like so:
>>>>
>>>> inline void* operator new(size_t, void *ptr) throw() {
>>>> return ptr;
>>>> }
>>>>
>>>> and so it's not defined in the runtime library. That's why I assume
>>>> the OPERATOR_NEW_ARRAY_PLACEMENT test fails: it declares
>>> the operator
>>>> and calls it without providing a definition to see if one exists in
>>>> the runtime. Unless the test finds one we need to provide our own
>>>> definition in our <new>. Otherwise we just declare it.
>>>>
>>>> Martin
>>>>
>>
>
>
Re: [STDCXX-709] ContainerData ctor and UserClass::from_char()
Posted by Martin Sebor <se...@roguewave.com>.
Eric Lemings wrote:
>
>
>> -----Original Message-----
>> From: Martin Sebor [mailto:msebor@gmail.com] On Behalf Of Martin Sebor
>> Sent: Monday, March 24, 2008 3:41 PM
>> To: dev@stdcxx.apache.org
>> Subject: Re: [STDCXX-709] ContainerData ctor and
>> UserClass::from_char()
>>
> ...
>> try to create a small test case reproducing it. I.e., create an
>> archive lib that allocates memory using the new expression and
>> a program that replaces operators new and delete, links with the
>> library and attempts to deallocate the memory allocated by the
>> library. See if the right operators are being called.
>
> I created a simple little test case.
>
> http://people.apache.org/~elemings/test02.tar.gz
>
> It works as it should on both platforms.
>
> I also created a little test case in trunk/tests/containers that
> links to the rwtest static library:
>
> #include <rw_new.h>
> #include <rw_value.h>
>
> int main () {
> UserClass* uc = UserClass::from_char("ab", 2);
> return 0;
> }
>
> This test case exhibits the same problem in STDCXX-709.
But the errors (SIGABRT) in the tests listed in STDCXX-709 are
independent of the build type. They happen across the board in
aCC 6.16 builds. I went back and looked at builds with earlier
releases of aCC on IPF. It looks like these tests have been
failing with all versions of aCC we tested with since 6.0 but
they were not failing with 5.57 back in November 2007. We
might want to run a round builds with that compiler to see
what the results are with the head of trunk today.
>
> It has something to do with the trunk/include/rw/_new.h header
> but I'm still not sure exactly what the problem is.
In light of the above I'm guessing what we're seeing is a code
generation issue. The runtime between aCC 5.57 and 6.x is the
same (as long as the same -AA or -Aa is being used, which it
is). What's different, IIRC, is the C++ front end. aCC 5 was
based on the original HP front end while aCC 6 uses the EDG
front end. That's a major difference.
Martin
Re: [STDCXX-709] ContainerData ctor and UserClass::from_char()
Posted by Martin Sebor <se...@roguewave.com>.
Eric Lemings wrote:
>
>
>> -----Original Message-----
>> From: Eric Lemings
>> Sent: Thursday, March 27, 2008 2:05 PM
>> To: 'dev@stdcxx.apache.org'
>> Subject: RE: [STDCXX-709] ContainerData ctor and
>> UserClass::from_char()
>>
>>
>>
>>> -----Original Message-----
>>> From: Martin Sebor [mailto:sebor@roguewave.com]
>>> Sent: Wednesday, March 26, 2008 4:19 PM
>>> To: dev@stdcxx.apache.org
>>> Subject: Re: [STDCXX-709] ContainerData ctor and
>>> UserClass::from_char()
>>>
>> ...
>>> It seems pretty clear that somewhere between the call TO
>>> operator new and the return FROM the function the pointer
>>> gets bumped up by 8 on LP64 (and 4 on ILP32 according to
>>> your observation). The only thing in between these two
>>> steps is the call to the UserClass ctor. So unless the
>>> ctor manages to change its own this pointer we're looking
>>> as a compiler bug. Either way, we need a small, isolated
>>> test case to understand how to deal with it...
>>>
>>> Martin
>> The pointer is being adjusted before the constructor is
>> called.
>>
>> I was looking yesterday at GCC's implementation of the
>> C++ ABI __cxa_vec_new2() function. There's a padding
>> argument that may be utilized in HP-UX aCC 6.x for some
>> unknown reason.
>>
>> Also, I thought the allocator in _rw_dispatch(), where
>> the ContainerTestCaseData object is being constructed,
>> could play some role in all this but looks like its
>> only used in the test function.
>>
>> Brad.
>
> Does HP-UX IPF have any sort of memory alignment restrictions
> that anyone is aware of?
Usually, the preferred (required on some systems) alignment
of a built-in type corresponds to the type's size. According
to HP, int and float are 4-byte aligned, and doubles are 8
byte aligned:
http://www.docs.hp.com/en/1552/comp_run.html#RN.CVT.NN100
AFAICT, malloc() returns pointers aligned on the 8-byte
boundary.
Martin
RE: [STDCXX-709] ContainerData ctor and UserClass::from_char()
Posted by Eric Lemings <Er...@roguewave.com>.
> -----Original Message-----
> From: Eric Lemings
> Sent: Thursday, March 27, 2008 2:05 PM
> To: 'dev@stdcxx.apache.org'
> Subject: RE: [STDCXX-709] ContainerData ctor and
> UserClass::from_char()
>
>
>
> > -----Original Message-----
> > From: Martin Sebor [mailto:sebor@roguewave.com]
> > Sent: Wednesday, March 26, 2008 4:19 PM
> > To: dev@stdcxx.apache.org
> > Subject: Re: [STDCXX-709] ContainerData ctor and
> > UserClass::from_char()
> >
> ...
> >
> > It seems pretty clear that somewhere between the call TO
> > operator new and the return FROM the function the pointer
> > gets bumped up by 8 on LP64 (and 4 on ILP32 according to
> > your observation). The only thing in between these two
> > steps is the call to the UserClass ctor. So unless the
> > ctor manages to change its own this pointer we're looking
> > as a compiler bug. Either way, we need a small, isolated
> > test case to understand how to deal with it...
> >
> > Martin
>
> The pointer is being adjusted before the constructor is
> called.
>
> I was looking yesterday at GCC's implementation of the
> C++ ABI __cxa_vec_new2() function. There's a padding
> argument that may be utilized in HP-UX aCC 6.x for some
> unknown reason.
>
> Also, I thought the allocator in _rw_dispatch(), where
> the ContainerTestCaseData object is being constructed,
> could play some role in all this but looks like its
> only used in the test function.
>
> Brad.
Does HP-UX IPF have any sort of memory alignment restrictions
that anyone is aware of?
RE: [STDCXX-709] ContainerData ctor and UserClass::from_char()
Posted by Eric Lemings <Er...@roguewave.com>.
> -----Original Message-----
> From: Martin Sebor [mailto:sebor@roguewave.com]
> Sent: Wednesday, March 26, 2008 4:19 PM
> To: dev@stdcxx.apache.org
> Subject: Re: [STDCXX-709] ContainerData ctor and
> UserClass::from_char()
>
...
>
> It seems pretty clear that somewhere between the call TO
> operator new and the return FROM the function the pointer
> gets bumped up by 8 on LP64 (and 4 on ILP32 according to
> your observation). The only thing in between these two
> steps is the call to the UserClass ctor. So unless the
> ctor manages to change its own this pointer we're looking
> as a compiler bug. Either way, we need a small, isolated
> test case to understand how to deal with it...
>
> Martin
The pointer is being adjusted before the constructor is
called.
I was looking yesterday at GCC's implementation of the
C++ ABI __cxa_vec_new2() function. There's a padding
argument that may be utilized in HP-UX aCC 6.x for some
unknown reason.
Also, I thought the allocator in _rw_dispatch(), where
the ContainerTestCaseData object is being constructed,
could play some role in all this but looks like its
only used in the test function.
Brad.
Re: [STDCXX-709] ContainerData ctor and UserClass::from_char()
Posted by Martin Sebor <se...@roguewave.com>.
Eric Lemings wrote:
>
>
>> -----Original Message-----
>> From: Eric Lemings [mailto:Eric.Lemings@roguewave.com]
>> Sent: Wednesday, March 26, 2008 10:55 AM
>> To: dev@stdcxx.apache.org
>> Subject: RE: [STDCXX-709] ContainerData ctor and
>> UserClass::from_char()
>>
>>
>>
> ...
>> I think you're right. I set a breakpoint in operator_new()
>> without trying to step into it and gdb hit it but it won't
>> step into it. I think I know why. gdb can't step into the
>> __cxa_vec_new2() function:
>>
>> #1 0x40ab2e0:0 in operator new[] (n=100)
>> at /amd/devco/lemings/work/stdcxx/trunk/tests/include/rw_new.h:184
>> #2 0x200000007ebbcd30:0 in __cxa_vec_new2+0x70 ()
>> from /usr/lib/hpux32/libCsup.so.1
>> #3 0x413cf60:0 in UserClass* __rw_from_char<UserClass>
>> (No.Identifier_0=0x0,
>> str=0x7fffe650 "ab", len=2, sorted=false)
>> at /amd/devco/lemings/work/stdcxx/trunk/tests/src/value.cpp:486
>>
>> Sometimes the __cxa_vec_new2() function is not linked in and gdb
>> can therefore step right into operator new[].
>>
>> I wonder if the presence/absence of this function and library has
>> anything to do with our problem?
>
> It looks like the pointer returned by operator_new is not the same
> pointer being assigned to the array pointer in value.cpp at line
> 485.
I'm seeing the same thing:
UserClass *UserClass::from_char(const char *, unsigned long, bool)
calls
T *__rw_from_char(T *, const char *, unsigned long, bool)
[with T = UserClass] (str = "ab", len = 2)
calls
void *operator new[](unsigned long)
calls
operator_new (168, 1)
which returns 6000000000041240
The pointer returned from operator new[] is 6000000000041240
[array = 6000000000041248, 2 elems]
The pointer assigned to the array variable in __rw_from_char
in the expression:
array = new T [strlen_];
is 6000000000041248.
It seems pretty clear that somewhere between the call TO
operator new and the return FROM the function the pointer
gets bumped up by 8 on LP64 (and 4 on ILP32 according to
your observation). The only thing in between these two
steps is the call to the UserClass ctor. So unless the
ctor manages to change its own this pointer we're looking
as a compiler bug. Either way, we need a small, isolated
test case to understand how to deal with it...
Martin
> Here's what I observed:
>
> (gdb) print *last
> $15 = {
> prev_ = 0x4002b9c0,
> next_ = 0x0,
> ptr_ = 0x400d3fd8,
> size_ = 100,
> id_ = 4294936458,
> self_ = 0x400d3fc0
> }
> (gdb) print last->prev_
> $16 = (struct Header *) 0x4002b9c0
> (gdb) print *(last->prev_)
> $17 = {
> prev_ = 0x0,
> next_ = 0x400d3fc0,
> ptr_ = 0x4002b9d8,
> size_ = 16,
> id_ = 0,
> self_ = 0x4002b9c0
> }
> (gdb) next
> 0x200000007ebbcd30:0 in __cxa_vec_new2+0x70 ()
> from /usr/lib/hpux32/libCsup.so.1
> (gdb) next
> Single stepping until exit from function __cxa_vec_new2,
> which has no line number information.
> 0x200000007ebbcd90:0 in __cxa_vec_new2+0xd0 ()
> from /usr/lib/hpux32/libCsup.so.1
> (gdb) up
> #1 0x413cf60:0 in UserClass* __rw_from_char<UserClass>
> (No.Identifier_0=0x0,
> str=0x7fffe650 "ab", len=2, sorted=false)
> at /amd/devco/lemings/work/stdcxx/trunk/tests/src/value.cpp:486
> 486 array = new T [strlen_];
> (gdb) list
> 481 }
> 482
> 483 T*array = 0;
> 484
> 485 _TRY {
> 486 array = new T [strlen_];
> 487 }
> 488 _CATCH (...) {
> 489
> 490 if (str_buf_ != str_)
> (gdb) next
> Single stepping until exit from function __cxa_vec_new2,
> which has no line number information.
> UserClass* __rw_from_char<UserClass> (No.Identifier_0=0x0,
> str=0x7fffe650 "ab", len=2, sorted=false)
> at /amd/devco/lemings/work/stdcxx/trunk/tests/src/value.cpp:498
> 498 for (size_t i = 0; i < strlen_; ++i)
> (gdb) print array
> $18 = (struct UserClass *) 0x400d3fdc
>
> Compare the array pointer at the very bottom to the value of last->ptr_
> near the top. Its off by 4 bytes.
>
> Brad.
RE: [STDCXX-709] ContainerData ctor and UserClass::from_char()
Posted by Eric Lemings <Er...@roguewave.com>.
> -----Original Message-----
> From: Eric Lemings [mailto:Eric.Lemings@roguewave.com]
> Sent: Wednesday, March 26, 2008 10:55 AM
> To: dev@stdcxx.apache.org
> Subject: RE: [STDCXX-709] ContainerData ctor and
> UserClass::from_char()
>
>
>
...
>
> I think you're right. I set a breakpoint in operator_new()
> without trying to step into it and gdb hit it but it won't
> step into it. I think I know why. gdb can't step into the
> __cxa_vec_new2() function:
>
> #1 0x40ab2e0:0 in operator new[] (n=100)
> at /amd/devco/lemings/work/stdcxx/trunk/tests/include/rw_new.h:184
> #2 0x200000007ebbcd30:0 in __cxa_vec_new2+0x70 ()
> from /usr/lib/hpux32/libCsup.so.1
> #3 0x413cf60:0 in UserClass* __rw_from_char<UserClass>
> (No.Identifier_0=0x0,
> str=0x7fffe650 "ab", len=2, sorted=false)
> at /amd/devco/lemings/work/stdcxx/trunk/tests/src/value.cpp:486
>
> Sometimes the __cxa_vec_new2() function is not linked in and gdb
> can therefore step right into operator new[].
>
> I wonder if the presence/absence of this function and library has
> anything to do with our problem?
It looks like the pointer returned by operator_new is not the same
pointer being assigned to the array pointer in value.cpp at line
485. Here's what I observed:
(gdb) print *last
$15 = {
prev_ = 0x4002b9c0,
next_ = 0x0,
ptr_ = 0x400d3fd8,
size_ = 100,
id_ = 4294936458,
self_ = 0x400d3fc0
}
(gdb) print last->prev_
$16 = (struct Header *) 0x4002b9c0
(gdb) print *(last->prev_)
$17 = {
prev_ = 0x0,
next_ = 0x400d3fc0,
ptr_ = 0x4002b9d8,
size_ = 16,
id_ = 0,
self_ = 0x4002b9c0
}
(gdb) next
0x200000007ebbcd30:0 in __cxa_vec_new2+0x70 ()
from /usr/lib/hpux32/libCsup.so.1
(gdb) next
Single stepping until exit from function __cxa_vec_new2,
which has no line number information.
0x200000007ebbcd90:0 in __cxa_vec_new2+0xd0 ()
from /usr/lib/hpux32/libCsup.so.1
(gdb) up
#1 0x413cf60:0 in UserClass* __rw_from_char<UserClass>
(No.Identifier_0=0x0,
str=0x7fffe650 "ab", len=2, sorted=false)
at /amd/devco/lemings/work/stdcxx/trunk/tests/src/value.cpp:486
486 array = new T [strlen_];
(gdb) list
481 }
482
483 T*array = 0;
484
485 _TRY {
486 array = new T [strlen_];
487 }
488 _CATCH (...) {
489
490 if (str_buf_ != str_)
(gdb) next
Single stepping until exit from function __cxa_vec_new2,
which has no line number information.
UserClass* __rw_from_char<UserClass> (No.Identifier_0=0x0,
str=0x7fffe650 "ab", len=2, sorted=false)
at /amd/devco/lemings/work/stdcxx/trunk/tests/src/value.cpp:498
498 for (size_t i = 0; i < strlen_; ++i)
(gdb) print array
$18 = (struct UserClass *) 0x400d3fdc
Compare the array pointer at the very bottom to the value of last->ptr_
near the top. Its off by 4 bytes.
Brad.
RE: [STDCXX-709] ContainerData ctor and UserClass::from_char()
Posted by Eric Lemings <Er...@roguewave.com>.
> -----Original Message-----
> From: Eric Lemings
> Sent: Wednesday, March 26, 2008 10:55 AM
> To: 'dev@stdcxx.apache.org'
> Subject: RE: [STDCXX-709] ContainerData ctor and
> UserClass::from_char()
>
>
>
...
>
> Sometimes the __cxa_vec_new2() function is not linked in and gdb
> can therefore step right into operator new[].
>
> I wonder if the presence/absence of this function and library has
> anything to do with our problem?
Disregard.
RE: [STDCXX-709] ContainerData ctor and UserClass::from_char()
Posted by Eric Lemings <Er...@roguewave.com>.
> -----Original Message-----
> From: Martin Sebor [mailto:msebor@gmail.com] On Behalf Of Martin Sebor
> Sent: Tuesday, March 25, 2008 10:58 PM
> To: dev@stdcxx.apache.org
> Subject: Re: [STDCXX-709] ContainerData ctor and
> UserClass::from_char()
>
> I doctored up the rwtest driver to print out progress messages
> and recompiled/reran 23.list.assign. The relevant portion of
> the test's output is below. It seems that operator_new() is
> being called after all, and the allegedly invalid pointer is
> actually one previously obtained from operator_new (400d1c7c).
> So I wonder if something else is going on, like some sort of
> data corruption in new.cpp. From the heap dump is seems clear
> that the pointer isn't on the list. Since it's allocated just
> a few calls previously, there's a very narrow window when it
> could be removed from the list (and the list corrupted). We
> need to find when this happens.
>
> # INFO (S1) (3 lines):
> # TEXT: std::list<UserClass>::assign(size_type, const_reference)
> # CLAUSE: lib.list.assign
>
> UserClass *UserClass::from_char(const char *, unsigned long, bool)
> T *__rw_from_char(T *, const char *, unsigned long, bool) [with T =
> UserClass] (str = "ab", len = 2) ==>
> void *operator new[](unsigned long)
> operator_new (100, 1)
> ==> 400d1c7c <<< ALLEGEDLY INVALID POINTER
> [str_ = 400d1c7c]
...
I think you're right. I set a breakpoint in operator_new()
without trying to step into it and gdb hit it but it won't
step into it. I think I know why. gdb can't step into the
__cxa_vec_new2() function:
#1 0x40ab2e0:0 in operator new[] (n=100)
at /amd/devco/lemings/work/stdcxx/trunk/tests/include/rw_new.h:184
#2 0x200000007ebbcd30:0 in __cxa_vec_new2+0x70 ()
from /usr/lib/hpux32/libCsup.so.1
#3 0x413cf60:0 in UserClass* __rw_from_char<UserClass>
(No.Identifier_0=0x0,
str=0x7fffe650 "ab", len=2, sorted=false)
at /amd/devco/lemings/work/stdcxx/trunk/tests/src/value.cpp:486
Sometimes the __cxa_vec_new2() function is not linked in and gdb
can therefore step right into operator new[].
I wonder if the presence/absence of this function and library has
anything to do with our problem?
Brad.
Re: [STDCXX-709] ContainerData ctor and UserClass::from_char()
Posted by Martin Sebor <se...@roguewave.com>.
I doctored up the rwtest driver to print out progress messages
and recompiled/reran 23.list.assign. The relevant portion of
the test's output is below. It seems that operator_new() is
being called after all, and the allegedly invalid pointer is
actually one previously obtained from operator_new (400d1c7c).
So I wonder if something else is going on, like some sort of
data corruption in new.cpp. From the heap dump is seems clear
that the pointer isn't on the list. Since it's allocated just
a few calls previously, there's a very narrow window when it
could be removed from the list (and the list corrupted). We
need to find when this happens.
# INFO (S1) (3 lines):
# TEXT: std::list<UserClass>::assign(size_type, const_reference)
# CLAUSE: lib.list.assign
UserClass *UserClass::from_char(const char *, unsigned long, bool)
T *__rw_from_char(T *, const char *, unsigned long, bool) [with T =
UserClass] (str = "ab", len = 2) ==>
void *operator new[](unsigned long)
operator_new (100, 1)
==> 400d1c7c <<< ALLEGEDLY INVALID POINTER
[str_ = 400d1c7c]
UserClass *UserClass::from_char(const char *, unsigned long, bool)
T *__rw_from_char(T *, const char *, unsigned long, bool) [with T =
UserClass] (str = "", len = 0) ==>
void *operator new[](unsigned long)
operator_new (4, 1)
==> 4004a19c
UserClass *UserClass::from_char(const char *, unsigned long, bool)
T *__rw_from_char(T *, const char *, unsigned long, bool) [with T =
UserClass] (str = "c", len = 1) ==>
void *operator new[](unsigned long)
operator_new (52, 1)
==> 4005fddc
void *operator new(unsigned long)
operator_new (12, 0)
void *operator new(unsigned long)
operator_new (1792, 0)
void *operator new[](unsigned long)
operator_new (2, 1)
# ERROR (S8) (4 lines):
# TEXT: /amd/devco/sebor/stdcxx/tests/src/new.cpp:211: operator delete[]
(0x400d1c7c): invalid pointer
# CLAUSE: lib.list.assign
# LINE: 209
Martin Sebor wrote:
> Eric Lemings wrote:
>>
> [...]
>> I also created a little test case in trunk/tests/containers that
>> links to the rwtest static library:
>>
>> #include <rw_new.h>
>> #include <rw_value.h>
>>
>> int main () {
>> UserClass* uc = UserClass::from_char("ab", 2);
>
> Did you forget delete[] uc here?
>
>> return 0;
>> }
>>
>> This test case exhibits the same problem in STDCXX-709.
>
> For me this little test runs fine both with and without the delete
> statement. I tried 11s and 15D builds.
>
> Martin
>
>>
>> It has something to do with the trunk/include/rw/_new.h header
>> but I'm still not sure exactly what the problem is.
>>
>> Brad.
>>
>
>
Re: [STDCXX-709] ContainerData ctor and UserClass::from_char()
Posted by Martin Sebor <se...@roguewave.com>.
Eric Lemings wrote:
>
[...]
> I also created a little test case in trunk/tests/containers that
> links to the rwtest static library:
>
> #include <rw_new.h>
> #include <rw_value.h>
>
> int main () {
> UserClass* uc = UserClass::from_char("ab", 2);
Did you forget delete[] uc here?
> return 0;
> }
>
> This test case exhibits the same problem in STDCXX-709.
For me this little test runs fine both with and without the delete
statement. I tried 11s and 15D builds.
Martin
>
> It has something to do with the trunk/include/rw/_new.h header
> but I'm still not sure exactly what the problem is.
>
> Brad.
>
RE: [STDCXX-709] ContainerData ctor and UserClass::from_char()
Posted by Eric Lemings <Er...@roguewave.com>.
> -----Original Message-----
> From: Martin Sebor [mailto:msebor@gmail.com] On Behalf Of Martin Sebor
> Sent: Monday, March 24, 2008 3:41 PM
> To: dev@stdcxx.apache.org
> Subject: Re: [STDCXX-709] ContainerData ctor and
> UserClass::from_char()
>
...
> try to create a small test case reproducing it. I.e., create an
> archive lib that allocates memory using the new expression and
> a program that replaces operators new and delete, links with the
> library and attempts to deallocate the memory allocated by the
> library. See if the right operators are being called.
I created a simple little test case.
http://people.apache.org/~elemings/test02.tar.gz
It works as it should on both platforms.
I also created a little test case in trunk/tests/containers that
links to the rwtest static library:
#include <rw_new.h>
#include <rw_value.h>
int main () {
UserClass* uc = UserClass::from_char("ab", 2);
return 0;
}
This test case exhibits the same problem in STDCXX-709.
It has something to do with the trunk/include/rw/_new.h header
but I'm still not sure exactly what the problem is.
Brad.
Re: [STDCXX-709] ContainerData ctor and UserClass::from_char()
Posted by Martin Sebor <se...@roguewave.com>.
The two versions of aCC are very different (based on a different
C++ front ends). Each also runs on a different OS and hardware.
I think significant differences are to be expected. That doesn't
mean that there isn't a problem in our aCC 6.16 configuration,
but neither does it imply there is one.
Eric Lemings wrote:
>
> In regards to STDCXX-709, note that there are no config differences
> in the delete operators, only the new operators.
These should be benign and unrelated to STDCXX-709.
FWIW, if you still suspect a mismatch between the allocation and
deallocation functions called from the tests I would suggest to
try to create a small test case reproducing it. I.e., create an
archive lib that allocates memory using the new expression and
a program that replaces operators new and delete, links with the
library and attempts to deallocate the memory allocated by the
library. See if the right operators are being called.
Martin
>
> Brad.
>
>> -----Original Message-----
>> From: Eric Lemings [mailto:Eric.Lemings@roguewave.com]
>> Sent: Monday, March 24, 2008 3:21 PM
>> To: dev@stdcxx.apache.org
>> Subject: RE: [STDCXX-709] ContainerData ctor and
>> UserClass::from_char()
>>
>>
>> I was just comparing the configuration differences for these
>> two platforms:
>>
>> HP-UX B.11.21/HP aCC 3.73
>> HP-UX B.11.31/HP aCC 6.16
>>
>> See http://people.apache.org/~elemings/diff.out.
>>
>> There seems to be way to many configuation differences. I think
>> we may have a much more serious problem on HP-UX ia64.
>>
>> Brad.
>>
>>> -----Original Message-----
>>> From: Martin Sebor [mailto:msebor@gmail.com] On Behalf Of
>> Martin Sebor
>>> Sent: Friday, March 21, 2008 5:10 PM
>>> To: dev@stdcxx.apache.org
>>> Subject: Re: [STDCXX-709] ContainerData ctor and
>>> UserClass::from_char()
>>>
>>> Eric Lemings wrote:
>>>>
>>>>
>>>>> -----Original Message-----
>>>>> From: Martin Sebor [mailto:sebor@roguewave.com]
>>>>> Sent: Friday, March 21, 2008 3:32 PM
>>>>> To: dev@stdcxx.apache.org
>>>>> Subject: Re: [STDCXX-709] ContainerData ctor and
>>>>> UserClass::from_char()
>>>>>
>>>> ...
>>>>> So you think there's a mismatch between the allocation function
>>>>> invoked in value.cpp and the deallocation function called in the
>>>>> header? Why would that be? IIUC, tests that replace operator new
>>>>> and operator delete (such as 23.list.assign) replace it for the
>>>>> whole process. If there's a mismatch, it can only be because
>>>>> the operators aren't replaced consistently. Making sure this
>>>>> replacement happens across the whole process, including any
>>>>> libraries, is the responsibility of the C++ runtime (i.e.,
>>>>> the compiler). If your analysis is correct, the C++ runtime
>>>>> on IPF would have to be buggy.
>>>>>
>>>>> Or did I misunderstand what you were trying to say?
>>>> Sounds about right.
>>>>
>>>> I just noticed there's a runtime link error in the config test
>>>> OPERATOR_NEW_ARRAY_PLACEMENT on HP-UX IPF platforms. May be the
>>>> culprit.
>>>>
>>>> [user@host]$ ./include/OPERATOR_NEW_ARRAY_PLACEMENT
>>>> /usr/lib/hpux32/dld.so: Unsatisfied code symbol '_ZnamPv' in load
>>>> module './stdcxx/include/OPERATOR_NEW_ARRAY_PLACEMENT'.
>>>> Killed
>>> That's a check for placement new in the runtime library. I don't
>>> think that has any bearing on the replaceability of operator new.
>>>
>>> I.e., the first one is not replaceable:
>>>
>>> void* operator new(size_t, void*) throw();
>>> void* operator new[](size_t, void*) throw();
>>>
>>> while the second one is:
>>>
>>> void* operator(size_t) throw (bad_alloc);
>>> void* operator[](size_t) throw (bad_alloc);
>>>
>>> The first form is usually defined inline in <new>, like so:
>>>
>>> inline void* operator new(size_t, void *ptr) throw() {
>>> return ptr;
>>> }
>>>
>>> and so it's not defined in the runtime library. That's why I assume
>>> the OPERATOR_NEW_ARRAY_PLACEMENT test fails: it declares
>> the operator
>>> and calls it without providing a definition to see if one exists in
>>> the runtime. Unless the test finds one we need to provide our own
>>> definition in our <new>. Otherwise we just declare it.
>>>
>>> Martin
>>>
>
RE: [STDCXX-709] ContainerData ctor and UserClass::from_char()
Posted by Eric Lemings <Er...@roguewave.com>.
In regards to STDCXX-709, note that there are no config differences
in the delete operators, only the new operators.
Brad.
> -----Original Message-----
> From: Eric Lemings [mailto:Eric.Lemings@roguewave.com]
> Sent: Monday, March 24, 2008 3:21 PM
> To: dev@stdcxx.apache.org
> Subject: RE: [STDCXX-709] ContainerData ctor and
> UserClass::from_char()
>
>
> I was just comparing the configuration differences for these
> two platforms:
>
> HP-UX B.11.21/HP aCC 3.73
> HP-UX B.11.31/HP aCC 6.16
>
> See http://people.apache.org/~elemings/diff.out.
>
> There seems to be way to many configuation differences. I think
> we may have a much more serious problem on HP-UX ia64.
>
> Brad.
>
> > -----Original Message-----
> > From: Martin Sebor [mailto:msebor@gmail.com] On Behalf Of
> Martin Sebor
> > Sent: Friday, March 21, 2008 5:10 PM
> > To: dev@stdcxx.apache.org
> > Subject: Re: [STDCXX-709] ContainerData ctor and
> > UserClass::from_char()
> >
> > Eric Lemings wrote:
> > >
> > >
> > >> -----Original Message-----
> > >> From: Martin Sebor [mailto:sebor@roguewave.com]
> > >> Sent: Friday, March 21, 2008 3:32 PM
> > >> To: dev@stdcxx.apache.org
> > >> Subject: Re: [STDCXX-709] ContainerData ctor and
> > >> UserClass::from_char()
> > >>
> > > ...
> > >> So you think there's a mismatch between the allocation function
> > >> invoked in value.cpp and the deallocation function called in the
> > >> header? Why would that be? IIUC, tests that replace operator new
> > >> and operator delete (such as 23.list.assign) replace it for the
> > >> whole process. If there's a mismatch, it can only be because
> > >> the operators aren't replaced consistently. Making sure this
> > >> replacement happens across the whole process, including any
> > >> libraries, is the responsibility of the C++ runtime (i.e.,
> > >> the compiler). If your analysis is correct, the C++ runtime
> > >> on IPF would have to be buggy.
> > >>
> > >> Or did I misunderstand what you were trying to say?
> > >
> > > Sounds about right.
> > >
> > > I just noticed there's a runtime link error in the config test
> > > OPERATOR_NEW_ARRAY_PLACEMENT on HP-UX IPF platforms. May be the
> > > culprit.
> > >
> > > [user@host]$ ./include/OPERATOR_NEW_ARRAY_PLACEMENT
> > > /usr/lib/hpux32/dld.so: Unsatisfied code symbol '_ZnamPv' in load
> > > module './stdcxx/include/OPERATOR_NEW_ARRAY_PLACEMENT'.
> > > Killed
> >
> > That's a check for placement new in the runtime library. I don't
> > think that has any bearing on the replaceability of operator new.
> >
> > I.e., the first one is not replaceable:
> >
> > void* operator new(size_t, void*) throw();
> > void* operator new[](size_t, void*) throw();
> >
> > while the second one is:
> >
> > void* operator(size_t) throw (bad_alloc);
> > void* operator[](size_t) throw (bad_alloc);
> >
> > The first form is usually defined inline in <new>, like so:
> >
> > inline void* operator new(size_t, void *ptr) throw() {
> > return ptr;
> > }
> >
> > and so it's not defined in the runtime library. That's why I assume
> > the OPERATOR_NEW_ARRAY_PLACEMENT test fails: it declares
> the operator
> > and calls it without providing a definition to see if one exists in
> > the runtime. Unless the test finds one we need to provide our own
> > definition in our <new>. Otherwise we just declare it.
> >
> > Martin
> >
>
RE: [STDCXX-709] ContainerData ctor and UserClass::from_char()
Posted by Eric Lemings <Er...@roguewave.com>.
I was just comparing the configuration differences for these
two platforms:
HP-UX B.11.21/HP aCC 3.73
HP-UX B.11.31/HP aCC 6.16
See http://people.apache.org/~elemings/diff.out.
There seems to be way to many configuation differences. I think
we may have a much more serious problem on HP-UX ia64.
Brad.
> -----Original Message-----
> From: Martin Sebor [mailto:msebor@gmail.com] On Behalf Of Martin Sebor
> Sent: Friday, March 21, 2008 5:10 PM
> To: dev@stdcxx.apache.org
> Subject: Re: [STDCXX-709] ContainerData ctor and
> UserClass::from_char()
>
> Eric Lemings wrote:
> >
> >
> >> -----Original Message-----
> >> From: Martin Sebor [mailto:sebor@roguewave.com]
> >> Sent: Friday, March 21, 2008 3:32 PM
> >> To: dev@stdcxx.apache.org
> >> Subject: Re: [STDCXX-709] ContainerData ctor and
> >> UserClass::from_char()
> >>
> > ...
> >> So you think there's a mismatch between the allocation function
> >> invoked in value.cpp and the deallocation function called in the
> >> header? Why would that be? IIUC, tests that replace operator new
> >> and operator delete (such as 23.list.assign) replace it for the
> >> whole process. If there's a mismatch, it can only be because
> >> the operators aren't replaced consistently. Making sure this
> >> replacement happens across the whole process, including any
> >> libraries, is the responsibility of the C++ runtime (i.e.,
> >> the compiler). If your analysis is correct, the C++ runtime
> >> on IPF would have to be buggy.
> >>
> >> Or did I misunderstand what you were trying to say?
> >
> > Sounds about right.
> >
> > I just noticed there's a runtime link error in the config test
> > OPERATOR_NEW_ARRAY_PLACEMENT on HP-UX IPF platforms. May be the
> > culprit.
> >
> > [user@host]$ ./include/OPERATOR_NEW_ARRAY_PLACEMENT
> > /usr/lib/hpux32/dld.so: Unsatisfied code symbol '_ZnamPv' in load
> > module './stdcxx/include/OPERATOR_NEW_ARRAY_PLACEMENT'.
> > Killed
>
> That's a check for placement new in the runtime library. I don't
> think that has any bearing on the replaceability of operator new.
>
> I.e., the first one is not replaceable:
>
> void* operator new(size_t, void*) throw();
> void* operator new[](size_t, void*) throw();
>
> while the second one is:
>
> void* operator(size_t) throw (bad_alloc);
> void* operator[](size_t) throw (bad_alloc);
>
> The first form is usually defined inline in <new>, like so:
>
> inline void* operator new(size_t, void *ptr) throw() {
> return ptr;
> }
>
> and so it's not defined in the runtime library. That's why I assume
> the OPERATOR_NEW_ARRAY_PLACEMENT test fails: it declares the operator
> and calls it without providing a definition to see if one exists in
> the runtime. Unless the test finds one we need to provide our own
> definition in our <new>. Otherwise we just declare it.
>
> Martin
>
Re: [STDCXX-709] ContainerData ctor and UserClass::from_char()
Posted by Martin Sebor <se...@roguewave.com>.
Eric Lemings wrote:
>
>
>> -----Original Message-----
>> From: Martin Sebor [mailto:sebor@roguewave.com]
>> Sent: Friday, March 21, 2008 3:32 PM
>> To: dev@stdcxx.apache.org
>> Subject: Re: [STDCXX-709] ContainerData ctor and
>> UserClass::from_char()
>>
> ...
>> So you think there's a mismatch between the allocation function
>> invoked in value.cpp and the deallocation function called in the
>> header? Why would that be? IIUC, tests that replace operator new
>> and operator delete (such as 23.list.assign) replace it for the
>> whole process. If there's a mismatch, it can only be because
>> the operators aren't replaced consistently. Making sure this
>> replacement happens across the whole process, including any
>> libraries, is the responsibility of the C++ runtime (i.e.,
>> the compiler). If your analysis is correct, the C++ runtime
>> on IPF would have to be buggy.
>>
>> Or did I misunderstand what you were trying to say?
>
> Sounds about right.
>
> I just noticed there's a runtime link error in the config test
> OPERATOR_NEW_ARRAY_PLACEMENT on HP-UX IPF platforms. May be the
> culprit.
>
> [user@host]$ ./include/OPERATOR_NEW_ARRAY_PLACEMENT
> /usr/lib/hpux32/dld.so: Unsatisfied code symbol '_ZnamPv' in load
> module './stdcxx/include/OPERATOR_NEW_ARRAY_PLACEMENT'.
> Killed
That's a check for placement new in the runtime library. I don't
think that has any bearing on the replaceability of operator new.
I.e., the first one is not replaceable:
void* operator new(size_t, void*) throw();
void* operator new[](size_t, void*) throw();
while the second one is:
void* operator(size_t) throw (bad_alloc);
void* operator[](size_t) throw (bad_alloc);
The first form is usually defined inline in <new>, like so:
inline void* operator new(size_t, void *ptr) throw() {
return ptr;
}
and so it's not defined in the runtime library. That's why I assume
the OPERATOR_NEW_ARRAY_PLACEMENT test fails: it declares the operator
and calls it without providing a definition to see if one exists in
the runtime. Unless the test finds one we need to provide our own
definition in our <new>. Otherwise we just declare it.
Martin
RE: [STDCXX-709] ContainerData ctor and UserClass::from_char()
Posted by Eric Lemings <Er...@roguewave.com>.
> -----Original Message-----
> From: Martin Sebor [mailto:sebor@roguewave.com]
> Sent: Friday, March 21, 2008 3:32 PM
> To: dev@stdcxx.apache.org
> Subject: Re: [STDCXX-709] ContainerData ctor and
> UserClass::from_char()
>
...
>
> So you think there's a mismatch between the allocation function
> invoked in value.cpp and the deallocation function called in the
> header? Why would that be? IIUC, tests that replace operator new
> and operator delete (such as 23.list.assign) replace it for the
> whole process. If there's a mismatch, it can only be because
> the operators aren't replaced consistently. Making sure this
> replacement happens across the whole process, including any
> libraries, is the responsibility of the C++ runtime (i.e.,
> the compiler). If your analysis is correct, the C++ runtime
> on IPF would have to be buggy.
>
> Or did I misunderstand what you were trying to say?
Sounds about right.
I just noticed there's a runtime link error in the config test
OPERATOR_NEW_ARRAY_PLACEMENT on HP-UX IPF platforms. May be the
culprit.
[user@host]$ ./include/OPERATOR_NEW_ARRAY_PLACEMENT
/usr/lib/hpux32/dld.so: Unsatisfied code symbol '_ZnamPv' in load
module './stdcxx/include/OPERATOR_NEW_ARRAY_PLACEMENT'.
Killed
Brad.
Re: [STDCXX-709] ContainerData ctor and UserClass::from_char()
Posted by Martin Sebor <se...@roguewave.com>.
Eric Lemings wrote:
>
>
>> -----Original Message-----
>> From: Eric Lemings [mailto:Eric.Lemings@roguewave.com]
>> Sent: Friday, March 21, 2008 2:36 PM
>> To: dev@stdcxx.apache.org
>> Subject: [STDCXX-709] ContainerData ctor and UserClass::from_char()
>>
>>
> ...
>> Now I'm sorta new to this UserClass and container testing but
>> but WTF is
>> going on here? char* and UserClass* are convertible certainly but
>> clearly not compatible.
>
> Ehh, darn. I got str and str_ mixed up.
I was just about to say that. It took me a while to figure
it out. Those names could have been chosen better...
>
> Anwyays, what does this have to do with STDCXX-709? I believe the
> _rw_find_block() function is not able to find the specified memory
> block because the array is initially allocated by the
> __rw_from_char() function (file tests/src/value.cpp, line 485)
> and therefore is not mananging this memory in its headers.
>
> So either a new handler needs to be added or the delete replacement
> needs to be removed.
So you think there's a mismatch between the allocation function
invoked in value.cpp and the deallocation function called in the
header? Why would that be? IIUC, tests that replace operator new
and operator delete (such as 23.list.assign) replace it for the
whole process. If there's a mismatch, it can only be because
the operators aren't replaced consistently. Making sure this
replacement happens across the whole process, including any
libraries, is the responsibility of the C++ runtime (i.e.,
the compiler). If your analysis is correct, the C++ runtime
on IPF would have to be buggy.
Or did I misunderstand what you were trying to say?
Martin
RE: [STDCXX-709] ContainerData ctor and UserClass::from_char()
Posted by Eric Lemings <Er...@roguewave.com>.
> -----Original Message-----
> From: Eric Lemings [mailto:Eric.Lemings@roguewave.com]
> Sent: Friday, March 21, 2008 2:36 PM
> To: dev@stdcxx.apache.org
> Subject: [STDCXX-709] ContainerData ctor and UserClass::from_char()
>
>
...
>
> Now I'm sorta new to this UserClass and container testing but
> but WTF is
> going on here? char* and UserClass* are convertible certainly but
> clearly not compatible.
Ehh, darn. I got str and str_ mixed up.
Anwyays, what does this have to do with STDCXX-709? I believe the
_rw_find_block() function is not able to find the specified memory
block because the array is initially allocated by the
__rw_from_char() function (file tests/src/value.cpp, line 485)
and therefore is not mananging this memory in its headers.
So either a new handler needs to be added or the delete replacement
needs to be removed.
If anyone can verify this analysis is correct, please do. :)
Brad.