bus error, resize vector

[imutate]

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 ?

[Daniel T.]

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.

[imutate]

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.

[Roland Pibinger]

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?

[imutate]

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");

[Howard]

<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

[imutate]

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

[Daniel T.]

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.

[imutate]

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.

[Larry Smith]

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.

[imutate]

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.

[Daniel T.]

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.

[imutate]

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) ?

[Greg Comeau]

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?

[imutate]

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.

[Daniel T.]

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.

[imutate]

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.

[imutate]

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.

[Daniel T.]

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.

[imutate]

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 ?

[Thomas J. Gritzan]

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

[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::out_of_range
what(): vector::_M_range_check
Aborted

[Kai-Uwe Bux]

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

[Daniel T.]

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.

[imutate]

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 ?

[Daniel T.]

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.

[imutate]

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

[Howard]

<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

[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<doublevecdbl;
typedef Vec<vecdblmatdbl;

[imutate]

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.

[Daniel T.]

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.

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

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.

[Greg]

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.

[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]

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.