bus error, resize vector

[Thomas J. Gritzan]

Now change all the op[] calls with at(). If you use all vectors, you can
do that with a global replace of '[' with "at(" and then globally
replace ']' with ")".

Do you mean change x to x(i) or something else ?

He meant with:

std::vector<int> vec;
int index = 42;

Change all occurences of
vec[index]
to
vec.at(index)

The at function does the same thing as operator[] but will throw an
exception when the index is out of bounds.

 

[imutate]

That will likely find your error real quick.

OK, yes it does not get far atall, I get an error (but no hint as to
what variable or part of the program)

terminate called after throwing an instance of std:ut_of_range
what(): vector::_M_range_check
Aborted

 

[Kai-Uwe Bux]

OK, yes it does not get far atall, I get an error (but no hint as to
what variable or part of the program)

terminate called after throwing an instance of std:ut_of_range
what(): vector::_M_range_check
Aborted

Hint: run the program in a debugger. Then get a calltrace from the moment
when it aborts. This should tell you which function has the bug.


Best

Kai-Uwe Bux

 

[Daniel T.]

OK, yes it does not get far atall, I get an error (but no hint as to
what variable or part of the program)

terminate called after throwing an instance of std:ut_of_range
what(): vector::_M_range_check Aborted

You are trying to access an array out of its bounds. Either use a
debugger and have it break on all exceptions, or go into the code at the
last place you know worked (based on how much output you got before it
crashed) and start looking at all the "at()" calls. The value passed
into one of them is too large.

 

[imutate]

You are trying to access an array out of its bounds. Either use a
debugger and have it break on all exceptions, or go into the code at the
last place you know worked (based on how much output you got before it
crashed) and start looking at all the "at()" calls. The value passed
into one of them is too large.

I put a std::cout and std::endl in the template ( [] function) and I
got a compiler message even though I included iostream. Why do I need
to change to at() calls if these are in the template ?

 

[Daniel T.]

You are trying to access an array out of its bounds. Either use a
debugger and have it break on all exceptions, or go into the code at the
last place you know worked (based on how much output you got before it
crashed) and start looking at all the "at()" calls. The value passed
into one of them is too large.

I put a std::cout and std::endl in the template ( [] function) and I
got a compiler message even though I included iostream. Why do I need
to change to at() calls if these are in the template ?

In your code you have something like:

myVec.at( i )

In the line before that, put:

assert( i < myVec.size() );

Do that everywhere you are using "at()".

When the code breaks, it will tell you what file and line number in that
file the problem is located at.

 

[imutate]

OK, I got this debug template working. It would be nice to see the
variable name of the offending object.

 

[Howard]

OK, I got this debug template working. It would be nice to see the
variable name of the offending object.

Is this in response to something? What "debug template"? Do you have a
question?

Please provide some context in your responses, by quoting the relevant
portion(s) of what you're responding to. This isn't a chat room, and it's a
pain in the butt to try to go back and forth between messages to see where
the conversation has been going. Check out other posts here (such as this
one ) to see what I mean.

Thanks,
-Howard

 

[imutate]

Is this in response to something? What "debug template"? Do you have a

question?

Please provide some context in your responses, by quoting the relevant
portion(s) of what you're responding to. This isn't a chat room, and it's a
pain in the butt to try to go back and forth between messages to see where
the conversation has been going. Check out other posts here (such as this
one ) to see what I mean.

Thanks,
-Howard

It is one of these snazy gadgets (don't correct this code, as I pasted
from another message)
essentially..

#include <vector>

template < typename T >
class Vec : public std::vector< T > {
public:
Vec() { }
Vec( int s ) : std::vector<T>(s) { }
T& operator[](int i) { return this -> at(i); }
const T& operator[](int i ) const { return this -> at(i); }
};

This was something I abandoned, but I got it working. So I based my
vectors on this now, for debugging.

typedef Vec<double> vecdbl;
typedef Vec<vecdbl> matdbl;

 

[imutate]

In your code you have something like:

myVec.at( i )

No because I got that template working, see my reply to Howard. (but
you know the one)

In the line before that, put:

assert( i < myVec.size() );

Do that everywhere you are using "at()".

When the code breaks, it will tell you what file and line number in that
file the problem is located at.

That won't do it, I already output at every place I write to these
vectors and there is no indication that I am assigning 3276..whatever
(actually 2^31 - 1 or such like).
Something else is corrupting this vector.

 

[Daniel T.]

Daniel T. wrote:

That won't do it, I already output at every place I write to these
vectors and there is no indication that I am assigning
3276..whatever (actually 2^31 - 1 or such like). Something else is
corrupting this vector.

The only way the vector can be corrupted is if you are dereferencing an
invalid pointer somewhere, or if you are going outside the bounds of
some other vector or array. The problem probably has nothing to do with
that particular vector at all. The problem is most assuredly not in the
vector code itself.

 

[imutate]

The only way the vector can be corrupted is if you are dereferencing an

invalid pointer somewhere, or if you are going outside the bounds of
some other vector or array. The problem probably has nothing to do with
that particular vector at all. The problem is most assuredly not in the
vector code itself.

I ran on a different machine and I get a different number assigned, it
looks more like a long int than the 32767 number I got in Linux. I
asserted the range and there is no problem until the error. I've only
got no other arrays (or vectors) and one pointer and it is a function
pointer, can I assert (or templatise) this too ?

It is along the lines of
typedef double fn(const double &x);
typedef fn *fnptr;

 

[Daniel T.]

I ran on a different machine and I get a different number assigned,
it looks more like a long int than the 32767 number I got in Linux.
I asserted the range and there is no problem until the error.

Then you are somehow putting that value into the vector, probably by
pushing an uninitialized variable into the vector.

I've only got no other arrays (or vectors) and one pointer and it is
a function pointer, can I assert (or templatise) this too ?

It is along the lines of
typedef double fn(const double &x);
typedef fn *fnptr;

Sure. Assign it the value "0" when you create the function pointer, then
assert( myFnptr != 0 ) before you use it.

 

[Greg]

Then you are somehow putting that value into the vector, probably by
pushing an uninitialized variable into the vector.


Sure. Assign it the value "0" when you create the function pointer, then
assert( myFnptr != 0 ) before you use it.

I found my mistake, it was a vector index problem, yes, indexing past
the end. I made a change and did not reflect the change across my app.
Better object design next time.

 

[Greg]

The STL vector does not throw any error if you index past the end, at
least not if you have reserved the space.

x.reserve(10);
x.push_back(whatever);
...x[0] // OK
...x[1] // Also "OK", no error.

 

[red floyd]

The STL vector does not throw any error if you index past the end, at
least not if you have reserved the space.

x.reserve(10);
x.push_back(whatever);
..x[0] // OK
..x[1] // Also "OK", no error.

True, but x[1] is UB. x.at(1) will throw.