By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
446,405 Members | 1,053 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 446,405 IT Pros & Developers. It's quick & easy.

bus error, resize vector

P: n/a
I get a bus (or is it buss) error when I resize a vector

typedef std::vector<doubledblvec;
n = 127;
dblvec rv;
rv.resize(n); // error happens here

Any clues ? I can post more info if required ?

Sep 29 '06 #1
Share this Question
Share on Google+
35 Replies


P: n/a
im*****@hotmail.co.uk wrote:
I get a bus (or is it buss) error when I resize a vector

typedef std::vector<doubledblvec;
n = 127;
dblvec rv;
rv.resize(n); // error happens here

Any clues ? I can post more info if required ?
The below code works perfectly. Try posting the code that actually
produced the error.

#include <vector>

int main()
{
typedef std::vector<doubledblvec;
int n = 127;
dblvec rv;
rv.resize(n); // error happens here
}

--
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.
Sep 29 '06 #2

P: n/a

Daniel T. wrote:
The below code works perfectly. Try posting the code that actually
produced the error.
Indeed. How can I do that the whole thing is too large to post, but
why is it relevant. As I said I can post more but why ?

DEBUG_LOG("fn1");
rv.resize(n); // error happens here
DEBUG_LOG("fn2");

I know the error happens at rv.resize(n) because I don't get the output
from the second DEBUG_LOG.

Sep 29 '06 #3

P: n/a
On 29 Sep 2006 11:36:55 -0700, im*****@hotmail.co.uk wrote:
>Daniel T. wrote:
>The below code works perfectly. Try posting the code that actually
produced the error.

Indeed. How can I do that the whole thing is too large to post, but
why is it relevant. As I said I can post more but why ?

DEBUG_LOG("fn1");
rv.resize(n); // error happens here
DEBUG_LOG("fn2");

I know the error happens at rv.resize(n) because I don't get the output
from the second DEBUG_LOG.
A bus error usually stems from misaligned objects, not from the code
you posted. Do you use a custom memory allocator?
Sep 29 '06 #4

P: n/a

Roland Pibinger wrote:
A bus error usually stems from misaligned objects, not from the code
you posted. Do you use a custom memory allocator?
Do you mean like malloc, alloc etc and C++ new ?
No I am not using any of those or third party. I am only using reserve
and resize. Actually I am not using reserve on this particular
variable. I just tried it and it also failed.

DEBUG_LOG("fn0");
rv.reserve(n); // error happens here now
DEBUG_LOG("fn1");
rv.resize(n); DEBUG_LOG("fn2");

Sep 29 '06 #5

P: n/a

<im*****@hotmail.co.ukwrote in message
news:11*********************@e3g2000cwe.googlegrou ps.com...
>I get a bus (or is it buss) error when I resize a vector

typedef std::vector<doubledblvec;
n = 127;
dblvec rv;
rv.resize(n); // error happens here

Any clues ? I can post more info if required ?
Probably a bus error. A buss error occurs when you make a mistake kissing
someone. :-)

Seriously, the problem may stem from earlier, apparently unrelated code.
Using uninitialized variables or using objects which have been deleted or
writing past the bounds of an array are examples of problems which can often
cause errors to occur later in the code. The code above, by itself, looks
fine.

-Howard

Sep 29 '06 #6

P: n/a

Howard wrote:
Probably a bus error. A buss error occurs when you make a mistake kissing
someone. :-)
lol, it is a good word.
http://en.wikipedia.org/wiki/Buss
Seriously, the problem may stem from earlier, apparently unrelated code.
Using uninitialized variables or using objects which have been deleted or
writing past the bounds of an array are examples of problems which can often
cause errors to occur later in the code. The code above, by itself, looks
fine.

-Howard
So as I'm mostly using std vectors, one of these is likely to be the
culprit.
Thanks

Sep 29 '06 #7

P: n/a
im*****@hotmail.co.uk wrote:
Daniel T. wrote:
>The below code works perfectly. Try posting the code that actually
produced the error.

Indeed. How can I do that the whole thing is too large to post, but
why is it relevant. As I said I can post more but why ?
Because if you don't post the code that is actually causing the problem,
then no one can help you. BTW, don't post the whole thing. Start pairing
it down until you have the smallest example possible that still exhibits
the error. Nine times out of ten just trying to do that will help you
find the problem on your own.
DEBUG_LOG("fn1");
rv.resize(n); // error happens here
DEBUG_LOG("fn2");

I know the error happens at rv.resize(n) because I don't get the output
from the second DEBUG_LOG.
resize is not broken. Some code that you wrote is causing the problem.
What type is 'n'?

--
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.
Sep 29 '06 #8

P: n/a

Daniel T. wrote:
resize is not broken. Some code that you wrote is causing the problem.
Yes, maybe I need to learn to use some kind of debugger to traceback
the problem.
What type is 'n'?
it is passed in as an int as in
void fn(.. , int n, ..)

I changed this to "const int &n" instead (this code is older code that
I started when I knew less) , but no that did not solve the problem.

Sep 29 '06 #9

P: n/a
im*****@hotmail.co.uk wrote:
Daniel T. wrote:
>resize is not broken. Some code that you wrote is causing the problem.

Yes, maybe I need to learn to use some kind of debugger to traceback
the problem.
>What type is 'n'?

it is passed in as an int as in
void fn(.. , int n, ..)

I changed this to "const int &n" instead (this code is older code that
I started when I knew less) , but no that did not solve the problem.

Are you checking that 'n' is not zero, and not negative?
How large might 'n' be?

If you're validating 'n' before using it, then I'd
look elswhere - something is probably trashing memory,
causing this failure as a side effect.
Sep 29 '06 #10

P: n/a

Larry Smith wrote:
Are you checking that 'n' is not zero, and not negative?
How large might 'n' be?
OK its way past my original post
n=127;
>
If you're validating 'n' before using it, then I'd
look elswhere - something is probably trashing memory,
causing this failure as a side effect.
I looked at all the std::vectors, they all seem to be sized. This
could be tricky, what else tends to do this ? I don't have any
pointers as such except for some function pointer, but since this gets
used lots and I checked it, it is unlikely to be that.

Sep 30 '06 #11

P: n/a
im*****@hotmail.co.uk wrote:
Larry Smith wrote:
>Are you checking that 'n' is not zero, and not negative?
How large might 'n' be?

OK its way past my original post
n=127;
>>
If you're validating 'n' before using it, then I'd look elswhere -
something is probably trashing memory, causing this failure as a
side effect.

I looked at all the std::vectors, they all seem to be sized. This
could be tricky, what else tends to do this ? I don't have any
pointers as such except for some function pointer, but since this gets
used lots and I checked it, it is unlikely to be that.
Here's a simple thing to do that might find the problem. Replace all
vector array references with the 'at' function. Try this:

First do a find and replace in all files from "vector" (or "std::vector"
if you didn't use any using directives) to "Vec".
Change all references of #include <vectorto #include "Vec.h"
Make a Vec.h file with the following in it:

#include <vector>

// taken from TC++PL 3rd Ed.

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

See if that causes the error to move somewhere closer to the actual
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.
Sep 30 '06 #12

P: n/a

Daniel T. wrote:
Here's a simple thing to do that might find the problem. Replace all
vector array references with the 'at' function. Try this:

First do a find and replace in all files from "vector" (or "std::vector"
if you didn't use any using directives) to "Vec".
Change all references of #include <vectorto #include "Vec.h"
Make a Vec.h file with the following in it:

#include <vector>

// taken from TC++PL 3rd Ed.

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

See if that causes the error to move somewhere closer to the actual
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.
I replaced my matvec.h with this

#include <vector>

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

typedef Vec<doublevecdbl;
typedef Vec<vecdblmatdbl;

The compiler went "nuts" threw too many messages to print here, but I
can post them. Is there anything obviously wrong with this template
definition (typo etc) ?

Sep 30 '06 #13

P: n/a
In article <11**********************@c28g2000cwb.googlegroups .com>,
<im*****@hotmail.co.ukwrote:
>
Daniel T. wrote:
>Here's a simple thing to do that might find the problem. Replace all
vector array references with the 'at' function. Try this:

First do a find and replace in all files from "vector" (or "std::vector"
if you didn't use any using directives) to "Vec".
Change all references of #include <vectorto #include "Vec.h"
Make a Vec.h file with the following in it:

#include <vector>

// taken from TC++PL 3rd Ed.

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

See if that causes the error to move somewhere closer to the actual
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.

I replaced my matvec.h with this

#include <vector>

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

typedef Vec<doublevecdbl;
typedef Vec<vecdblmatdbl;

The compiler went "nuts" threw too many messages to print here, but I
can post them. Is there anything obviously wrong with this template
definition (typo etc) ?
If that's the exact code, see:

http://www.comeaucomputing.com/techtalk/#usestd
--
Greg Comeau / 20 years of Comeauity! Intel Mac Port now in alpha!
Comeau C/C++ ONLINE == http://www.comeaucomputing.com/tryitout
World Class Compilers: Breathtaking C++, Amazing C99, Fabulous C90.
Comeau C/C++ with Dinkumware's Libraries... Have you tried it?
Sep 30 '06 #14

P: n/a

im*****@hotmail.co.uk wrote:
The compiler went "nuts" threw too many messages to print here, but I
can post them. Is there anything obviously wrong with this template
definition (typo etc) ?
OK, different errors now, I will start a new post.

Sep 30 '06 #15

P: n/a
im*****@hotmail.co.uk wrote:
Daniel T. wrote:
Here's a simple thing to do that might find the problem. Replace all
vector array references with the 'at' function. Try this:

I replaced my matvec.h with this

#include <vector>

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

typedef Vec<doublevecdbl;
typedef Vec<vecdblmatdbl;

The compiler went "nuts" threw too many messages to print here, but I
can post them. Is there anything obviously wrong with this template
definition (typo etc) ?
Just post the first three errors to us and let's see what they say.

--
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.
Sep 30 '06 #16

P: n/a

Daniel T. wrote:
Just post the first three errors to us and let's see what they say.
Sorry, I removed this template declaration on advice from someone else,
they made a criticism. Perhaps if you could explain the context and
removed the typos it might help. Also the namespace helps too.

Sep 30 '06 #17

P: n/a
I changed it back to composition and now I get a different error
message at runtime. Doing a resize on a std::vector I get glibc
detected malloc memory corruption. The difference now is that I don't
use any arrays now, all std::vectors. Some of these are vectors of
structs.

Sep 30 '06 #18

P: n/a
In article <11**********************@m7g2000cwm.googlegroups. com>,
im*****@hotmail.co.uk wrote:
I changed it back to composition and now I get a different error
message at runtime. Doing a resize on a std::vector I get glibc
detected malloc memory corruption.
That's telling you that at some earlier time, you wrote to memory you
didn't have access to.
The difference now is that I don't
use any arrays now, all std::vectors. Some of these are vectors of
structs.
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 ")".

That will likely find your error real quick.

--
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.
Sep 30 '06 #19

P: n/a
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[i] to x(i) or something else ?

Sep 30 '06 #20

P: n/a
im*****@hotmail.co.uk wrote:
>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[i] to x(i) or something else ?
He meant with:

std::vector<intvec;
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.

--
Thomas
http://www.netmeister.org/news/learn2quote.html
Sep 30 '06 #21

P: n/a
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::out_of_range
what(): vector::_M_range_check
Aborted

Oct 1 '06 #22

P: n/a
im*****@hotmail.co.uk wrote:
>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::out_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
Oct 1 '06 #23

P: n/a
im*****@hotmail.co.uk wrote:
>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::out_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.

--
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.
Oct 1 '06 #24

P: n/a

Daniel T. wrote:
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 ?

Oct 1 '06 #25

P: n/a
In article <11**********************@m73g2000cwd.googlegroups .com>,
im*****@hotmail.co.uk wrote:
Daniel T. wrote:
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.

--
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.
Oct 1 '06 #26

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

Oct 1 '06 #27

P: n/a

<im*****@hotmail.co.ukwrote in message
news:11**********************@e3g2000cwe.googlegro ups.com...
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

Oct 2 '06 #28

P: n/a
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<doublevecdbl;
typedef Vec<vecdblmatdbl;

Oct 2 '06 #29

P: n/a

Daniel T. wrote:
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.

Oct 2 '06 #30

P: n/a
im*****@hotmail.co.uk wrote:
Daniel T. wrote:
>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.
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.

--
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.
Oct 2 '06 #31

P: n/a
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;

Oct 3 '06 #32

P: n/a
im*****@hotmail.co.uk wrote:
>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.
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.

--
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.
Oct 4 '06 #33

P: n/a

Daniel T. wrote:
im*****@hotmail.co.uk wrote:
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.

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.

--
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.
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.

Oct 4 '06 #34

P: n/a
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.

Oct 4 '06 #35

P: n/a
Greg wrote:
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.
Oct 4 '06 #36

This discussion thread is closed

Replies have been disabled for this discussion.