Return-Path: 
 <dev-return-7146-apmail-stdcxx-dev-archive=stdcxx.apache.org@stdcxx.apache.org>
Delivered-To: apmail-stdcxx-dev-archive@www.apache.org
Received: (qmail 24178 invoked from network); 26 Mar 2008 16:55:26 -0000
Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2)
  by minotaur.apache.org with SMTP; 26 Mar 2008 16:55:26 -0000
Received: (qmail 5407 invoked by uid 500); 26 Mar 2008 16:55:25 -0000
Delivered-To: apmail-stdcxx-dev-archive@stdcxx.apache.org
Received: (qmail 5386 invoked by uid 500); 26 Mar 2008 16:55:25 -0000
Mailing-List: contact dev-help@stdcxx.apache.org; run by ezmlm
Precedence: bulk
List-Help: <mailto:dev-help@stdcxx.apache.org>
List-Unsubscribe: <mailto:dev-unsubscribe@stdcxx.apache.org>
List-Post: <mailto:dev@stdcxx.apache.org>
List-Id: <dev.stdcxx.apache.org>
Reply-To: dev@stdcxx.apache.org
Delivered-To: mailing list dev@stdcxx.apache.org
Received: (qmail 5377 invoked by uid 99); 26 Mar 2008 16:55:25 -0000
Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230)
    by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 26 Mar 2008 09:55:25 -0700
X-ASF-Spam-Status: No, hits=-0.0 required=10.0
	tests=SPF_PASS
X-Spam-Check-By: apache.org
Received-SPF: pass (nike.apache.org: local policy)
Received: from [208.30.140.160] (HELO moroha.roguewave.com) (208.30.140.160)
    by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 26 Mar 2008 16:54:37 +0000
Received: from exchmail01.Blue.Roguewave.Com (exchmail01.blue.roguewave.com
 [10.22.129.22])
	by moroha.roguewave.com (8.13.6/8.13.6) with ESMTP id m2QGsv7m005929
	for <dev@stdcxx.apache.org>; Wed, 26 Mar 2008 16:54:57 GMT
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: [STDCXX-709] ContainerData ctor and UserClass::from_char()
Date: Wed, 26 Mar 2008 10:55:22 -0600
Message-ID: 
 <CFFDD219128FD94FB4F92B99F52D0A49010A3698@exchmail01.Blue.Roguewave.Com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [STDCXX-709] ContainerData ctor and UserClass::from_char()
Thread-Index: AciO/lBOR0SteV70RteVhgJFSFbI7AAVGv/w
References: 
 <CFFDD219128FD94FB4F92B99F52D0A49010A3688@exchmail01.Blue.Roguewave.Com>
 <CFFDD219128FD94FB4F92B99F52D0A49010A3689@exchmail01.Blue.Roguewave.Com>
 <47E42941.8040704@roguewave.com>
 <CFFDD219128FD94FB4F92B99F52D0A49010A368A@exchmail01.Blue.Roguewave.Com>
 <47E44038.5090404@roguewave.com>
 <CFFDD219128FD94FB4F92B99F52D0A49010A368B@exchmail01.Blue.Roguewave.Com>
 <CFFDD219128FD94FB4F92B99F52D0A49010A368C@exchmail01.Blue.Roguewave.Com>
 <47E82005.50006@roguewave.com>
 <CFFDD219128FD94FB4F92B99F52D0A49010A3694@exchmail01.Blue.Roguewave.Com>
 <47E9BBD7.4060606@roguewave.com> <47E9D7CD.9060003@roguewave.com>
From: "Eric Lemings" <Eric.Lemings@roguewave.com>
To: <dev@stdcxx.apache.org>
X-Virus-Checked: Checked by ClamAV on apache.org

=20

> -----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=20
> UserClass::from_char()
>=20
> 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.
>=20
> # INFO (S1) (3 lines):
> # TEXT: std::list<UserClass>::assign(size_type, const_reference)
> # CLAUSE: lib.list.assign
>=20
> UserClass *UserClass::from_char(const char *, unsigned long, bool)
> T *__rw_from_char(T *, const char *, unsigned long, bool) [with T =3D=20
> UserClass] (str =3D "ab", len =3D 2) =3D=3D>
>      void *operator new[](unsigned long)
>          operator_new (100, 1)
>                      =3D=3D> 400d1c7c   <<< ALLEGEDLY INVALID POINTER
> [str_ =3D 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=3D100)
    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=3D0x0,
    str=3D0x7fffe650 "ab", len=3D2, sorted=3Dfalse)
    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.