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::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
#include
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()
Eric Lemings wrote:
[...]
I also created a little test case in trunk/tests/containers that
links to the rwtest static library:
#include
#include
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()
Eric Lemings wrote:
-Original Message-
From: Martin Sebor [mailto:[EMAIL PROTECTED] 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
#include
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()
> -Original Message-
> From: Martin Sebor [mailto:[EMAIL PROTECTED] 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
#include
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: svn commit: r640831 - /stdcxx/trunk/include/sstream.cc
> -Original Message-
> From: Martin Sebor [mailto:[EMAIL PROTECTED] On Behalf Of Martin Sebor
> Sent: Tuesday, March 25, 2008 5:11 PM
> To: dev@stdcxx.apache.org
> Subject: Re: svn commit: r640831 - /stdcxx/trunk/include/sstream.cc
>
> Any idea what caused it? I've gone through the recent history
> of the function and this looks like the likely change might
> be this one:
>
>http://svn.apache.org/viewvc?view=rev&revision=442675
>
> but the test wasn't failing. Maybe because the test doesn't
> cause the buffer to reallocate?
I think the bug introduced in
http://svn.apache.org/viewvc?view=rev&revision=380995
since the overflow() and xsputn() started calling the str() for
reallocate the buffer.
rev 442675:
---
+if (this->_C_is_out ()) {
+this->setp (this->_C_buffer, this->_C_buffer +
this->_C_bufsize);
+
+if (__s != __buf || this->_C_state & (ios_base::app |
ios_base::ate))
+this->pbump (__slen); // seek to end
}
---
After that change setp() resets pptr to pbase, then pbump() seeks pptr
to end always,
when str() is called from xsputn() or overflow() (the str() is called to
reallocate buffer,
so __s != __buf). The original position of pptr is lost.
rev 442675:
---
if (this->_C_is_out ()) {
this->setp (this->_C_buffer, this->_C_buffer +
this->_C_bufsize);
-if (__s != __buf || this->_C_state & (ios_base::app |
ios_base::ate))
-this->pbump (__slen); // seek to end
+if ( __s != __buf && this->_C_state & ios_base::in
+|| this->_C_state & (ios_base::app | ios_base::ate)) {
+// in input or append/ate modes seek to end
+// (see also lwg issue 562 for clarification)
+this->pbump (__slen);
+}
}
---
After that change setp() resets the pptr to pbase, then if _C_state &
ios_base::in != 0
then pbump() seeks pptr to end. In both cases the original position of
pptr is lost.
In STDCXX-515 the stringstream is used (_C_state & ios_base::in != 0)
and subsequent
output to stream is appended to end of the buffer despite of that pptr
is not points to end
due to seek(-1), ios_base::cur).
In STDCXX-795 the ostringstream is used (_C_state & ios_base::in == 0)
and subsequent
output to stream is inserted from the begin of the buffer.
Farid.
Re: svn commit: r640831 - /stdcxx/trunk/include/sstream.cc
Any idea what caused it? I've gone through the recent history
of the function and this looks like the likely change might
be this one:
http://svn.apache.org/viewvc?view=rev&revision=442675
but the test wasn't failing. Maybe because the test doesn't
cause the buffer to reallocate?
Martin
[EMAIL PROTECTED] wrote:
Author: faridz
Date: Tue Mar 25 07:33:02 2008
New Revision: 640831
URL: http://svn.apache.org/viewvc?rev=640831&view=rev
Log:
2008-03-25 Farid Zaripov <[EMAIL PROTECTED]>
STDCXX-792
* include/sstream.cc (str): Save pptr and restore is at the end if
str() is called with internal buffer to increase the capacity of
buffer (i.e. from xsputn() or overflow()).
(xsputn): Remove fix for STDCXX-515 because the pptr now is
preserved in str().
Modified:
stdcxx/trunk/include/sstream.cc
Modified: stdcxx/trunk/include/sstream.cc
URL:
http://svn.apache.org/viewvc/stdcxx/trunk/include/sstream.cc?rev=640831&r1=640830&r2=640831&view=diff
==
--- stdcxx/trunk/include/sstream.cc (original)
+++ stdcxx/trunk/include/sstream.cc Tue Mar 25 07:33:02 2008
@@ -82,8 +82,10 @@
_ValueAlloc __alloc;
// new buffer and size
-char_type *__buf;
-_RWSTD_SIZE_T __bufsize = __slen;
+char_type*__buf;
+_RWSTD_SIZE_T __bufsize = __slen;
+// saved offset of pptr
+_RWSTD_STREAMSIZE __off = -1;
if (__s == this->_C_buffer) {
// special case: str(_C_buffer, _C_bufsize + N) called
@@ -94,6 +96,8 @@
// set `slen' to the number of initialized characters
// in the buffer
__slen = this->egptr () - this->pbase ();
+// save the offset of pptr
+__off = this->pptr () - this->pbase ();
}
if (this->_C_bufsize < __bufsize) {
@@ -166,8 +170,12 @@
if (this->_C_is_out ()) {
this->setp (this->_C_buffer, this->_C_buffer + this->_C_bufsize);
-if ( __s != __buf && this->_C_state & ios_base::in
-|| this->_C_state & (ios_base::app | ios_base::ate)) {
+if (0 <= __off) {
+// restore the pptr
+this->pbump (__off);
+}
+else if ( this->_C_state & ios_base::in
+ || this->_C_state & (ios_base::app | ios_base::ate)) {
// in input or append/ate modes seek to end
// (see also lwg issue 562 for clarification)
this->pbump (__slen);
@@ -204,15 +212,9 @@
__off = this->pbase () - __s;
}
-// preserve current pptr() since str() would seek to end
-const streamsize __cur = this->pptr () - this->pbase ();
-
// grow the buffer if necessary to accommodate the whole
// string plus the contents of the buffer up to pptr()
str (this->_C_buffer, __bufsize);
-
-// restore pptr()
-this->pbump (__cur - (this->pptr () - this->pbase ()));
_RWSTD_ASSERT (__n <= this->epptr () - this->pptr ());
RE: NEW_OFLOW_SAFE config test
> -Original Message- > From: Martin Sebor [mailto:[EMAIL PROTECTED] On Behalf Of Martin Sebor > Sent: Tuesday, March 25, 2008 4:42 PM > To: dev@stdcxx.apache.org > Subject: Re: NEW_OFLOW_SAFE config test > > Farid Zaripov wrote: > > Hmm. The NEW_THROWS.cpp before this change also used > size_t without > > including the stddef.h: > > > http://svn.apache.org/viewvc/stdcxx/trunk/etc/config/src/NEW_T > HROWS.cpp? > > revision=611451&view=markup&pathrev=634731 > > But it included stdio.h, didn't it? And stdio defines size_t. > No big deal though. we caught it early enough that we can fix > it without it having caused any major problems. Ok. Let me add the #include in all config tests where size_t type is used for the reliability. Farid.
Re: NEW_OFLOW_SAFE config test
Farid Zaripov wrote: -Original Message- From: Martin Sebor [mailto:[EMAIL PROTECTED] On Behalf Of Martin Sebor Sent: Tuesday, March 25, 2008 3:46 AM To: dev@stdcxx.apache.org Subject: Re: NEW_OFLOW_SAFE config test Eric Lemings wrote: Here's an error compiling the NEW_OFLOW_SAFE.cpp config test: aCC -mt -I. -AA +w +W392 +W655 +W684 +W818 +W819 +W849 +W2193 +W2236 +W2261 +W2340 +W240 1 +W2487 +W4227 +W4229 +W4231 +W4235 +W4237 +W4249 +W4255 +W4272 +W4284 +W4285 +W4286 +W42 96 +W4297 +W3348 -c /amd/devco/lemings/work/stdcxx/trunk.gofish/etc/config/src/NEW_OFLOW_ SAFE.cpp -o NEW_OFLOW_SAFE.o "/amd/devco/lemings/work/stdcxx/trunk.gofish/etc/config/src/NEW_OFLOW_ SA FE.cpp", line 46: error #2020: identifier "size_t" is undefined void* p = ::operator new (size_t (-1)); ^ Shouldn't 'size_t' be replaced with '_RWSTD_SIZE_T'? Or one of the standard headers should be included (e.g. , )? The latter. This regression was introduced here: http://svn.apache.org/viewvc?view=rev&revision=634731 Hmm. The NEW_THROWS.cpp before this change also used size_t without including the stddef.h: http://svn.apache.org/viewvc/stdcxx/trunk/etc/config/src/NEW_THROWS.cpp? revision=611451&view=markup&pathrev=634731 But it included stdio.h, didn't it? And stdio defines size_t. No big deal though. we caught it early enough that we can fix it without it having caused any major problems. Martin
RE: NEW_OFLOW_SAFE config test
> -Original Message- > From: Martin Sebor [mailto:[EMAIL PROTECTED] On Behalf Of Martin Sebor > Sent: Tuesday, March 25, 2008 3:46 AM > To: dev@stdcxx.apache.org > Subject: Re: NEW_OFLOW_SAFE config test > > Eric Lemings wrote: > > > > Here's an error compiling the NEW_OFLOW_SAFE.cpp config test: > > > > aCC -mt -I. -AA +w +W392 +W655 +W684 +W818 +W819 +W849 > +W2193 +W2236 > > +W2261 +W2340 +W240 > > 1 +W2487 +W4227 +W4229 +W4231 +W4235 +W4237 +W4249 +W4255 +W4272 > > +W4284 > > +W4285 +W4286 +W42 > > 96 +W4297 +W3348 -c > > > /amd/devco/lemings/work/stdcxx/trunk.gofish/etc/config/src/NEW_OFLOW_ > > SAFE.cpp -o NEW_OFLOW_SAFE.o > > > "/amd/devco/lemings/work/stdcxx/trunk.gofish/etc/config/src/NEW_OFLOW_ > > SA > > FE.cpp", line 46: > > error #2020: identifier "size_t" is undefined > > void* p = ::operator new (size_t (-1)); > > ^ > > > > Shouldn't 'size_t' be replaced with '_RWSTD_SIZE_T'? Or one of the > > standard headers should be included (e.g. , )? > > The latter. This regression was introduced here: >http://svn.apache.org/viewvc?view=rev&revision=634731 Hmm. The NEW_THROWS.cpp before this change also used size_t without including the stddef.h: http://svn.apache.org/viewvc/stdcxx/trunk/etc/config/src/NEW_THROWS.cpp? revision=611451&view=markup&pathrev=634731 Farid.
