stdcxx-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Martin Sebor <se...@roguewave.com>
Subject Re: [STDCXX-709] ContainerData ctor and UserClass::from_char()
Date Wed, 26 Mar 2008 22:19:20 GMT
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.


Mime
View raw message