Re: gdb discrepancy in c++ iterators
On Sat, 29 Mar 2003, Fred Ma wrote:
Hello,
I'm having the following problem only on cygwin,
not on solaris 8. I have a sanity-check program:
#includevector
#includeiostream
using namespace std;
int main(void)
{
vectorint vi(3);
vectorint::iterator it_vi = vi.begin();
cout Hello world.;
}
I compile it with gcc 3.2 use
gdb2003-03-03-cvs(cygwin-special) to view
vi.begin() and it_vi. They are different:
(gdb) p vi.begin()
$1 = {iteratorstd::random_access_iterator_tag,int,int,int*,int =
{No data fields}, _M_current = 0xc7e44589}
(gdb) p it_vi
$2 = {iteratorstd::random_access_iterator_tag,int,int,int*,int =
{No data fields}, _M_current = 0xa041de0}
Why are they different? If I actually dereference the iterators,
they contain the same thing. But I want to deal with the iterators
themselves. In particular, I want a conditional breakpoint to trigger
when it_vi==vi.begin()+4. gdb won't let you add 4 to a random
access iterator, so I have to use the _M_current member data.
Since they are not the same above, I can't do that. Thanks for
any light on why they differ.
Fred
Umm, you do know that calling vi.begin() will create a *new* iterator,
right? As for it working on other systems, they may have different
implementations of STL iterators.
Igor
--
http://cs.nyu.edu/~pechtcha/
|\ _,,,---,,_[EMAIL PROTECTED]
ZZZzz /,`.-'`'-. ;-;;,_[EMAIL PROTECTED]
|,4- ) )-,_. ,\ ( `'-' Igor Pechtchanski
'---''(_/--' `-'\_) fL a.k.a JaguaR-R-R-r-r-r-.-.-. Meow!
Oh, boy, virtual memory! Now I'm gonna make myself a really *big* RAMdisk!
-- /usr/games/fortune
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Bug reporting: http://cygwin.com/bugs.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
Re: gdb discrepancy in c++ iterators
Igor Pechtchanski wrote:
On Sat, 29 Mar 2003, Fred Ma wrote:
Hello,
I'm having the following problem only on cygwin,
not on solaris 8. I have a sanity-check program:
#includevector
#includeiostream
using namespace std;
int main(void)
{
vectorint vi(3);
vectorint::iterator it_vi = vi.begin();
cout Hello world.;
}
I compile it with gcc 3.2 use
gdb2003-03-03-cvs(cygwin-special) to view
vi.begin() and it_vi. They are different:
(gdb) p vi.begin()
$1 = {iteratorstd::random_access_iterator_tag,int,int,int*,int =
{No data fields}, _M_current = 0xc7e44589}
(gdb) p it_vi
$2 = {iteratorstd::random_access_iterator_tag,int,int,int*,int =
{No data fields}, _M_current = 0xa041de0}
Why are they different? If I actually dereference the iterators,
they contain the same thing. But I want to deal with the iterators
themselves. In particular, I want a conditional breakpoint to trigger
when it_vi==vi.begin()+4. gdb won't let you add 4 to a random
access iterator, so I have to use the _M_current member data.
Since they are not the same above, I can't do that. Thanks for
any light on why they differ.
Fred
Umm, you do know that calling vi.begin() will create a *new* iterator,
right? As for it working on other systems, they may have different
implementations of STL iterators.
Igor
Yes, I know that. I'm comparing it on a different system but
with the same version of gcc, so I expect the STL implementation
to be the same. I have to qualify that; the cygwin version is
gcc3.2 20020927 (prerelease). The solaris version is 3.2.1,
and since there is no 3.2.0 on www.gun.org, cygwin's gcc is
probably a tenative version of the solaris version. But I don't
expect great changes, at least not as big as the definition of
_M_current. If iterators are suped up pointers, then _M_current
is the primitive pointer that is suped up. From the properly
functioning gcc/gdb on solaris, it_vi and vi.begin() contain the
same value for _M_current. If I dereference _M_current in
either iterator, I get the right object value. If I try this on cygwin,
*it_vi._M_current returns the right value, but
*(vi.begin()._M_current) is an error because the memory
location can't be accessed. In the actual program that
I'm trying to debug, none of the changes made to a aggregate
vector elements via it_vi seem to have any effect, probably
because of the differing _M_current values (in that case,
vi.begin()._M_current is pointing to valid memory space).
About the fact that the iterators are different, gdb's print
command prints the object itself, including data members,
*not* the address of the object. So the fact that the iterators
are different should not make the objects' value different.
Another strange clue, if it is that: if I print *it_vi._M_current
in the full blown program, vi.begin()_M_current actually changes
values (by itself) so as to be the same as it_vi._M_current.
Very bizzare.
Fred
P.S. The gdb version on cygwin (at top) is relatively
recent. In contrast, on solaris8 (where things seem to
behave right), it's gdb 4.17, copyright 1998.
--
Fred Ma, [EMAIL PROTECTED]
Carleton University, Dept. of Electronics
1125 Colonel By Drive, Ottawa, Ontario
Canada, K1S 5B6
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Bug reporting: http://cygwin.com/bugs.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
Re: gdb discrepancy in c++ iterators
On Sat, 29 Mar 2003, Fred Ma wrote:
Igor Pechtchanski wrote:
On Sat, 29 Mar 2003, Fred Ma wrote:
Hello,
I'm having the following problem only on cygwin,
not on solaris 8. I have a sanity-check program:
#includevector
#includeiostream
using namespace std;
int main(void)
{
vectorint vi(3);
vectorint::iterator it_vi = vi.begin();
cout Hello world.;
}
I compile it with gcc 3.2 use
gdb2003-03-03-cvs(cygwin-special) to view
vi.begin() and it_vi. They are different:
(gdb) p vi.begin()
$1 = {iteratorstd::random_access_iterator_tag,int,int,int*,int =
{No data fields}, _M_current = 0xc7e44589}
(gdb) p it_vi
$2 = {iteratorstd::random_access_iterator_tag,int,int,int*,int =
{No data fields}, _M_current = 0xa041de0}
Why are they different? If I actually dereference the iterators,
they contain the same thing. But I want to deal with the iterators
themselves. In particular, I want a conditional breakpoint to trigger
when it_vi==vi.begin()+4. gdb won't let you add 4 to a random
access iterator, so I have to use the _M_current member data.
Since they are not the same above, I can't do that. Thanks for
any light on why they differ.
Fred
Umm, you do know that calling vi.begin() will create a *new* iterator,
right? As for it working on other systems, they may have different
implementations of STL iterators.
Igor
Yes, I know that. I'm comparing it on a different system but
with the same version of gcc, so I expect the STL implementation
to be the same. I have to qualify that; the cygwin version is
gcc3.2 20020927 (prerelease). The solaris version is 3.2.1,
and since there is no 3.2.0 on www.gun.org, cygwin's gcc is
probably a tenative version of the solaris version. But I don't
expect great changes, at least not as big as the definition of
_M_current. If iterators are suped up pointers, then _M_current
is the primitive pointer that is suped up. From the properly
functioning gcc/gdb on solaris, it_vi and vi.begin() contain the
same value for _M_current. If I dereference _M_current in
either iterator, I get the right object value. If I try this on cygwin,
*it_vi._M_current returns the right value, but
*(vi.begin()._M_current) is an error because the memory
location can't be accessed. In the actual program that
I'm trying to debug, none of the changes made to a aggregate
vector elements via it_vi seem to have any effect, probably
because of the differing _M_current values (in that case,
vi.begin()._M_current is pointing to valid memory space).
About the fact that the iterators are different, gdb's print
command prints the object itself, including data members,
*not* the address of the object. So the fact that the iterators
are different should not make the objects' value different.
Another strange clue, if it is that: if I print *it_vi._M_current
in the full blown program, vi.begin()_M_current actually changes
values (by itself) so as to be the same as it_vi._M_current.
Very bizzare.
Fred
P.S. The gdb version on cygwin (at top) is relatively
recent. In contrast, on solaris8 (where things seem to
behave right), it's gdb 4.17, copyright 1998.
--
Fred Ma, [EMAIL PROTECTED]
Depending on the optimization level you used to compile the program (and
on the flags in the gcc specs file, and the gcc compilation options, which
are surely different on the two systems), it's quite possible gdb got
confused about where in the program you were with respect to the (probably
inlined) execution of vi.begin() (or, for that matter, the copy
constructor).
As possible workarounds: Did you consider trying to compile without
optimization? Also, in the original program, does the bug you're looking
for manifest itself if you introduce an extra counter into the loop? If
so, you could use that counter's value as the condition for the
breakpoint. There are also counted breakpoints in gdb that you could make
use of...
Igor
--
http://cs.nyu.edu/~pechtcha/
|\ _,,,---,,_[EMAIL PROTECTED]
ZZZzz /,`.-'`'-. ;-;;,_[EMAIL PROTECTED]
|,4- ) )-,_. ,\ ( `'-' Igor Pechtchanski
'---''(_/--' `-'\_) fL a.k.a JaguaR-R-R-r-r-r-.-.-. Meow!
Oh, boy, virtual memory! Now I'm gonna make myself a really *big* RAMdisk!
-- /usr/games/fortune
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Bug reporting: http://cygwin.com/bugs.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
Re: gdb discrepancy in c++ iterators
Igor Pechtchanski wrote: Depending on the optimization level you used to compile the program (and on the flags in the gcc specs file, and the gcc compilation options, which are surely different on the two systems), it's quite possible gdb got confused about where in the program you were with respect to the (probably inlined) execution of vi.begin() (or, for that matter, the copy constructor). As possible workarounds: Did you consider trying to compile without optimization? Also, in the original program, does the bug you're looking for manifest itself if you introduce an extra counter into the loop? If so, you could use that counter's value as the condition for the breakpoint. There are also counted breakpoints in gdb that you could make use of... Igor Yes, I've read that optimization can make things unpredicatable and confusing for debugging. I didn't turn on optimization. But this is not just a debugger confusion. The program misbehaves. I've embedded code to print out the vector elements after some action on it. No changes take effect (on cygwin), probably due to the differing iterator values (aggregate values, that is). On solaris, the program runs as expected i.e. the changes take effect. Exactly the same code, almost the same compiler. I'll try some of the gdb features you pointed out, but since the problem manifests itself in the program behaviour (and not just when using gdb), it would be a surprise to see it as a gdb problem (or my use of it). Thanks for the pointers. Fred -- Fred Ma, [EMAIL PROTECTED] Carleton University, Dept. of Electronics 1125 Colonel By Drive, Ottawa, Ontario Canada, K1S 5B6 -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
