stdcxx-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Eric Lemings" <>
Subject RE: [STDCXX-709] ContainerData ctor and UserClass::from_char()
Date Wed, 26 Mar 2008 16:55:22 GMT

> -----Original Message-----
> From: Martin Sebor [] On Behalf Of Martin Sebor
> Sent: Tuesday, March 25, 2008 10:58 PM
> To:
> 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/
#3  0x413cf60:0 in UserClass* __rw_from_char<UserClass>
    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?


View raw message