vector error, how to debug

[imutate]

I have an integer variable and I am testing it as follows

#define NULL_VAL -1
...
if (x[i].id != NULL_VAL)
{
std::cout << x[i].id << std::endl;
...
}

The output is
32767aborted

The index i=0 and this is being assigned to, so somewhere it is getting
overwritten.
x is defined as a vector over a template

Vec<sx;

struct s{
int id;
...
}

Is there a way I can trace back and see where this value is coming from
?

[Victor Bazarov]

im*****@hotmail.co.uk wrote:

I have an integer variable and I am testing it as follows

#define NULL_VAL -1
..
if (x[i].id != NULL_VAL)
{
std::cout << x[i].id << std::endl;
..
}

The output is
32767aborted

The index i=0 and this is being assigned to, so somewhere it is
getting overwritten.
x is defined as a vector over a template

Vec<sx;

This vector contains no elements. To add elements, use 'push_back'.

Read FAQ 5.8, while you're at it.

>
struct s{
int id;
..
}

Is there a way I can trace back and see where this value is coming
from ?

The error is on line 42 of your program.

V
--
Please remove capital 'A's when replying by e-mail
I do not respond to top-posted replies, please don't ask

[Daniel T.]

In article <11**********************@h48g2000cwc.googlegroups .com>,
im*****@hotmail.co.uk wrote:

I have an integer variable and I am testing it as follows

#define NULL_VAL -1
..
if (x[i].id != NULL_VAL)
{
std::cout << x[i].id << std::endl;
..
}

Replace your code above with:

assert( i >= 0 && i < x.size() );
if ( x.at(i).id != NULL_VAL ) {
std::cout << x[i].id << std::endl;
}

What does it do then?

--
There are two things that simply cannot be doubted, logic and perception.
Doubt those, and you no longer*have anyone to discuss your doubts with,
nor any ability to discuss them.

[Kai-Uwe Bux]

im*****@hotmail.co.uk wrote:

I have an integer variable and I am testing it as follows

#define NULL_VAL -1
..
if (x[i].id != NULL_VAL)
{
std::cout << x[i].id << std::endl;
..
}

The output is
32767aborted

The index i=0 and this is being assigned to, so somewhere it is getting
overwritten.
x is defined as a vector over a template

Vec<sx;

struct s{
int id;
..
}

Is there a way I can trace back and see where this value is coming from?

The C++ language has no built feature for this. You can use a debugger: you
can then step through the program an watch the variable i. However,
debuggers are platform specific and specifics about particular debuggers
are therefore off-topic in this group. You may find better help in a forum
dedicated to your compiler or OS.
Best

Kai-Uwe Bux

[imutate]

Sorry, i is 0 and earlier in my code I set this to id to 0, I know this
because I'm printing it out there, so the only logical explanation is
that it is getting corrupted somewhere else. OK, if the dubugger is
off topic, I'll look elsewhere, thanks anyway.

[Daniel T.]

In article <11*********************@m7g2000cwm.googlegroups.c om>,
im*****@hotmail.co.uk wrote:

Sorry, i is 0 and earlier in my code I set this to id to 0, I know this
because I'm printing it out there, so the only logical explanation is
that it is getting corrupted somewhere else. OK, if the dubugger is
off topic, I'll look elsewhere, thanks anyway.

What does x.size() return?

--
There are two things that simply cannot be doubted, logic and perception.
Doubt those, and you no longer*have anyone to discuss your doubts with,
nor any ability to discuss them.

[imutate]

I am getting confused I should have pasted the actuall code. The
problem is the large vvalue is causing the abort none of the sizes goes
that high, I am looking to run a debugger to find where the index is
corrupted to this high value.

[Salt_Peter]

im*****@hotmail.co.uk wrote:

I have an integer variable and I am testing it as follows

#define NULL_VAL -1
..
if (x[i].id != NULL_VAL)
{
std::cout << x[i].id << std::endl;
..
}

The output is
32767aborted

The index i=0 and this is being assigned to, so somewhere it is getting
overwritten.

obviously, its being overwritten because its an index (or counter if
you prefer). That what indexes do.

x is defined as a vector over a template

no, x is a templated vector of type s elements.

>
Vec<sx;

struct s{
int id;
..
}

Is there a way I can trace back and see where this value is coming from
?

Why not show the code that is generating the (probably expected) output
you see?
32767 looks like the max numeric_limits for a short or 16 bit integer
on whatever platform/compiler you are running. Here is a test for you:

#include <iostream>
#include <ostream>
#include <limits>

int main()
{
int nlimit = std::numeric_limits< int >::max();
std::cout << nlimit << std::endl;
}

What do you get?

[Mike Wahler]

<im*****@hotmail.co.ukwrote in message
news:11********************@m73g2000cwd.googlegrou ps.com...

>I am getting confused I should have pasted the actuall code. The
problem is the large vvalue is causing the abort none of the sizes goes
that high, I am looking to run a debugger to find where the index is
corrupted to this high value.

I'm pretty sure Victor has identified your problem:

When you create a vector, *it is empty*, it contains
no elements. So any indexed access (e.g. [0]) will
produce undefined behavior (you're asking for the
value of something which does not exist.) First
put some elements in your vector, then you can
examine their values. But make sure the index you
use is at least one less than the value returned
by the vector's 'size()' member function (indices
start at zero).

And yes, the actual code is the only way we can
know for sure what's wrong.

-Mike

>

[Mike Wahler]

"Mike Wahler" <mk******@mkwahler.netwrote in message
news:RO*****************@newsread4.news.pas.earthl ink.net...

>
<im*****@hotmail.co.ukwrote in message
news:11********************@m73g2000cwd.googlegrou ps.com...

>>I am getting confused I should have pasted the actuall code. The
problem is the large vvalue is causing the abort none of the sizes goes
that high, I am looking to run a debugger to find where the index is
corrupted to this high value.

I'm pretty sure Victor has identified your problem:

When you create a vector,

as in your example,

*it is empty*, it contains
no elements.

I needed to qualify my previous statement
because there are other ways to create a vector
which does contain elements (via contructors
other than default as you used).

-Mike

[imutate]

I needed to qualify my previous statement

because there are other ways to create a vector
which does contain elements (via contructors
other than default as you used).

-Mike

I use reserve and push_back (not resize)
Something is coruupting this vector.

[Salt_Peter]

im*****@hotmail.co.uk wrote:

I needed to qualify my previous statement
because there are other ways to create a vector
which does contain elements (via contructors
other than default as you used).

-Mike

I use reserve and push_back (not resize)
Something is coruupting this vector.

Yes, probably your code.
Containers like vectors, specifically std::vectors, are containers that
have been refined, tested, retested, rerefined and then tested again
until near perfection. These containers have truely been scrutinized to
exhaustion (and beyond). When appropriately employed, such containers
are practically guarenteed to remain consistant and bug-proof.
For starters, one requirement that a std::vector imposes on its
element-type (the template parameter) is that it be copyable and
assigneable (copy ctor and op=(), compiler-generated or not.). Thats a
requirement, not an option.
Without seeing code, we can't tell you what you are doing wrong. What
we do know is that you are doing something undefined or expecting
something that can't happen.

What kills me is that by posting some code or a brief, compileable
reconstruction, you are guarenteed to get a fair shake at the pros and
cons. With responses and issues scrutinized by millions - including the
founders of the language / libraries themselves. That is truely
priceless.
Its your choice if you choose to remain in the dark.

[Daniel T.]

im*****@hotmail.co.uk wrote:

>I needed to qualify my previous statement because there are other
ways to create a vector which does contain elements (via
contructors other than default as you used).

I use reserve and push_back (not resize) Something is coruupting
this vector.

Like I told you before (in the thread titled "bus error, resize vector",
you are going outside the bounds of one of your vectors. Put asserts in
to find out which one.

--
There are two things that simply cannot be doubted, logic and perception.
Doubt those, and you no longer*have anyone to discuss your doubts with,
nor any ability to discuss them.

[Pete Becker]

Daniel T. wrote:

>
assert( i >= 0 && i < x.size() );
if ( x.at(i).id != NULL_VAL ) {

Why check the bounds twice?

--

-- Pete

Author of "The Standard C++ Library Extensions: a Tutorial and
Reference." For more information about this book, see
www.petebecker.com/tr1book.

[Michiel.Salters]

Pete Becker wrote:

Daniel T. wrote:

assert( i >= 0 && i < x.size() );
if ( x.at(i).id != NULL_VAL ) {

Why check the bounds twice?

Well, assert(size_t(i) < x.size()) is a bit obscure. But if you refer
to the extra check that
at() does, that is always present even if the assert check isn't. I can
imagine using this
mechanism if 'i' was /probably/ OK, i.e. it comes from some external
system that is
supposed to cooperate. If debugging problems with the whole system, I'd
like to
jump to the debugger with all data structures still on the stack, so
the assert is OK.
If the end user has this problem, I just want to know at what point it
happens. For that
I'll need to print a message. Debugging the results of x[i] for invalid
i is a lot harder.

Michiel.

[Daniel T.]

Pete Becker <pe********@acm.orgwrote:

Daniel T. wrote:

assert( i >= 0 && i < x.size() );
if ( x.at(i).id != NULL_VAL ) {

Why check the bounds twice?

Because the OP started a thread earlier about his problem (see "bus
error, resize vector".) I had him change all uses of op[] to at() and he
said his program no longer had the bus error, that it crashed much
earlier in the program. He doesn't know how to use the debugger, so I
told him to put asserts before each use of at() to find out exactly
where it crashed. He instead started a new thread with his original
problem as if he never had help with this before.

I'm trying to encourage him to put the at()s back in (to avoid the
problem in general) and use asserts to find this specific problem.

--
There are two things that simply cannot be doubted, logic and perception.
Doubt those, and you no longer*have anyone to discuss your doubts with,
nor any ability to discuss them.

[imutate]

Daniel T. wrote:

Like I told you before (in the thread titled "bus error, resize vector",
you are going outside the bounds of one of your vectors. Put asserts in
to find out which one.

What is actually happening in my code is quite complicated and I did
not explain it correctly.
Essentially I have two vectors, the first is getting corrupted in some
way causing a spurious integer to be written to one of the elements.
This integer is then being used to index another vector and that is
where the error is becoming visible. So I know which vector is being
incorrectly indexed, but I don't know where this value is coming from.

[Daniel T.]

im*****@hotmail.co.uk wrote:

Daniel T. wrote:

>Like I told you before (in the thread titled "bus error, resize
vector", you are going outside the bounds of one of your vectors.
Put asserts in to find out which one.

What is actually happening in my code is quite complicated and I did
not explain it correctly. Essentially I have two vectors, the first
is getting corrupted in some way causing a spurious integer to be
written to one of the elements. This integer is then being used to
index another vector and that is where the error is becoming
visible. So I know which vector is being incorrectly indexed, but I
don't know where this value is coming from.

Then you only know of one place where the vector is being incorrectly
indexed. There is likely another place.

--
There are two things that simply cannot be doubted, logic and perception.
Doubt those, and you no longer*have anyone to discuss your doubts with,
nor any ability to discuss them.

[Howard]

<im*****@hotmail.co.ukwrote in message
news:11*********************@i42g2000cwa.googlegro ups.com...

Daniel T. wrote:

>Like I told you before (in the thread titled "bus error, resize vector",
you are going outside the bounds of one of your vectors. Put asserts in
to find out which one.

What is actually happening in my code is quite complicated and I did
not explain it correctly.
Essentially I have two vectors, the first is getting corrupted in some
way causing a spurious integer to be written to one of the elements.
This integer is then being used to index another vector and that is
where the error is becoming visible. So I know which vector is being
incorrectly indexed, but I don't know where this value is coming from.

So, you found where the invalid index was being used to access a vector.
And then you found that that index was coming from the value _stored_ in
another vector. Correct? Ok, now you have to find out how those value get
stored into that vector in the first place. Something in your code is
writing an invalid value there. But we have no way of knowing where that
invalid value comes from. We can't see your code (since you haven't posted
it here).

It probably gets there because you write it there, with push_back for
example. Or, it may get there because you've got broken code elsewhere.
But we certainly can't tell from here.

You need to either learn to use your debugger, or else post a minimal,
compilable, example here which demonstrates the problem.

Or, you could go back to your code and analyze where it's wrong. Look
especially at the places where you write to the vector. How do you make
sure that the values in that vector are valid indexes into the other vector?
(And how do you know that they _remain_ valid later in the program?)

You could add assert statements where you write to the vector, which make
sure that the value you're writing is a valid index into the other vector.
That might show you if you attempt to put a bad value there. (But it won't
tell you if that value is still good later. If you delete stuff from the
other vector, for example, then how do you handle indexes that point at the
deleted stuff?)

And if you're 100% absolutely positively sure that the code which writes
those index values to the vector is correct, and will never ever write an
invalid value, and that those values will always _remain_ valid, then the
problem just may be somewhere else entirely. Perhaps you're overwriting
memory somewhere, such as writing past the end of an array (including
C-style strings, which are just char arrays). Or perhaps you're
dereferencing a pointer to a deleted object. We have no way of knowing.
Only you can tell, by examining your code, or by using your debugger, or by
posting code here which exhibits the problem.

-Howard