Eric Lemings wrote:
-----Original Message-----
From: Eric Lemings [mailto:[EMAIL PROTECTED]
Sent: Wednesday, March 26, 2008 10:55 AM
To: [email protected]
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.
