Need helpin figuing out Segmentation fault when calling size() of STL vector

[silverburgh.meryl]

Hi,

I have a segmentation fault in line 66 of GroupResult.h and I can't
figure out why that causes any problem, I appreciate if anyone can
help.

line 66 of Result.h:

66 size_t size() const { return _bdl.size(); }

where _bdl is a private attribute of

class Result
{
private:
int _type;
vector<BlockData*> _bdl;

};

I step thru the debugger, _bdl is not null. So I can't understand why
calling '_bdl.size()' returns a Segmentation fault.

Any help is appreciated.
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread -1208583648 (LWP 9292)]
0x03edeffb in std::vector<BlockData*, std::allocator<BlockData*>

::begin (this=0x9) at /usr/lib/gcc/i386-redhat-linux/4.0.2/../../../../include/c++/4.0.2/bits/stl_vector.h:343 /usr/include/c++/4.0.2/bits/stl_vector.h:343:12255:beg:0x3edeffb
(gdb) bt
#0 0x03edeffb in std::vector<BlockData*, std::allocator<BlockData*>::begin (this=0x9) at /usr/lib/gcc/i386-redhat-linux/4.0.2/../../../../include/c++/4.0.2/bits/stl_vector.h:343 #1 0x03edf08d in std::vector<BlockData*, std::allocator<BlockData*>::size (this=0x9) at /usr/lib/gcc/i386-redhat-linux/4.0.2/../../../../include/c++/4.0.2/bits/stl_vector.h:403

#2 0x03edf0ca in GroupResult::size (this=0x1) at Result.h:66
#3 0x03f11e98 in PageBreaker::handleOverLap (this=0xbf97a63c) at
PageBreaker.cpp:274

[Howard Hinnant]

In article <11**********************@i39g2000cwa.googlegroups .com>,
"si***************@gmail.com" <si***************@gmail.com> wrote:

Hi,

I have a segmentation fault in line 66 of GroupResult.h and I can't
figure out why that causes any problem, I appreciate if anyone can
help.

line 66 of Result.h:

66 size_t size() const { return _bdl.size(); }

where _bdl is a private attribute of

class Result
{
private:
int _type;
vector<BlockData*> _bdl;

};

I step thru the debugger, _bdl is not null. So I can't understand why
calling '_bdl.size()' returns a Segmentation fault.

Any help is appreciated.

Somebody, somewhere has stepped on your Result prior to you printing out
size().

I like to give my class an invariants() member:

class Result
{
public:
bool invariants() const;
private:
int _type;
vector<BlockData*> _bdl;

};

In invariants() I check all of the things must always be true for the
type. If they are all true I return true, else I return false. You can
then sprinkle your code with exceptions or asserts until you find out
where your invariants are being violated.

Example:
void foo()
{
int stuff[4];
Result r;
assert(r.invariants());
// do things with r
// ...
assert(r.invariants());
// do things with stuff
for (int i = 0; i <= 4; ++i)
stuff[i] = i;
assert(r.invariants());
return r;
}

-Howard

[Axter]

si***************@gmail.com wrote:

where _bdl is a private attribute of

class Result
{
private:
int _type;
vector<BlockData*> _bdl;

};

I recommend against using variable names that begin with an underscore,
because it makes your code none-portable.
IAW C++ standard, variable names that begin with an underscore are
reserved for the implementation.
If you need to use an underscore, use trailing underscores instead.
vector<BlockData*> _bdl; //This is NOT portable
vector<BlockData*> bdl_; //This is portable

I also recommend you use smart pointers instead of raw pointers in your
vector.
Consider using boost::shared_ptr, or the following more efficient smart
pointer:
http://axter.com/smartptr

By using the above smart pointer, you automate memory management, and
you get automatic deep copy cloning of your pointee.

Your current segment fault error may be related to your code's attempt
to do manual memory management.
It might be performming early deletion, or duplicate deletions. If you
use a smart pointer, you can avoid such logic errors.

[Rolf Magnus]

si***************@gmail.com wrote:

Hi,

I have a segmentation fault in line 66 of GroupResult.h and I can't
figure out why that causes any problem, I appreciate if anyone can
help.

line 66 of Result.h:

66 size_t size() const { return _bdl.size(); }

where _bdl is a private attribute of

class Result
{
private:
int _type;
vector<BlockData*> _bdl;

};

I step thru the debugger, _bdl is not null.
It can't be. It's not a pointer.
So I can't understand why calling '_bdl.size()' returns a Segmentation
fault.

Any help is appreciated.
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread -1208583648 (LWP 9292)]
0x03edeffb in std::vector<BlockData*, std::allocator<BlockData*>

::begin (this=0x9) at
::/usr/lib/gcc/i386-redhat-linux/4.0.2/../../../../include/c++/4.0.2/bits/stl_vector.h:343 /usr/include/c++/4.0.2/bits/stl_vector.h:343:12255:beg:0x3edeffb
(gdb) bt
#0 0x03edeffb in std::vector<BlockData*, std::allocator<BlockData*>

::begin (this=0x9) at
::/usr/lib/gcc/i386-redhat-linux/4.0.2/../../../../include/c++/4.0.2/bits/stl_vector.h:343

#1 0x03edf08d in std::vector<BlockData*, std::allocator<BlockData*>

::size (this=0x9) at
::/usr/lib/gcc/i386-redhat-linux/4.0.2/../../../../include/c++/4.0.2/bits/stl_vector.h:403

#2 0x03edf0ca in GroupResult::size (this=0x1) at Result.h:66

^^^^^^^^
This looks fishy. Also the "this=0x9" parts before. It seems those objects
are all part of an object you are trying to access through a null pointer.

#3 0x03f11e98 in PageBreaker::handleOverLap (this=0xbf97a63c) at
PageBreaker.cpp:274

[Howard]

"Axter" <go****@axter.com> wrote in message
news:11*********************@u72g2000cwu.googlegro ups.com...

si***************@gmail.com wrote:

where _bdl is a private attribute of

class Result
{
private:
int _type;
vector<BlockData*> _bdl;

};

I recommend against using variable names that begin with an underscore,
because it makes your code none-portable.
IAW C++ standard, variable names that begin with an underscore are
reserved for the implementation.
If you need to use an underscore, use trailing underscores instead.
vector<BlockData*> _bdl; //This is NOT portable
vector<BlockData*> bdl_; //This is portable

Not so. If the leading undescore is followed by a capital letter or another
underscore, then you're correct... it's "reserved for the implementation",
meaning you shouldn't use it yourself. Otherwise, it's legal according to
the standard to precede the variable name with a single underscore.

-Howard

[Howard]

<si***************@gmail.com> wrote in message
news:11**********************@i39g2000cwa.googlegr oups.com...

Hi,

I have a segmentation fault in line 66 of GroupResult.h and I can't
figure out why that causes any problem, I appreciate if anyone can
help.

line 66 of Result.h:

66 size_t size() const { return _bdl.size(); }

where _bdl is a private attribute of

class Result
{
private:
int _type;
vector<BlockData*> _bdl;

};

I step thru the debugger, _bdl is not null.
It can't be NULL, since it's not a pointer.
So I can't understand why
calling '_bdl.size()' returns a Segmentation fault.

Any help is appreciated.
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread -1208583648 (LWP 9292)]
0x03edeffb in std::vector<BlockData*, std::allocator<BlockData*>

::begin (this=0x9) at
/usr/lib/gcc/i386-redhat-linux/4.0.2/../../../../include/c++/4.0.2/bits/stl_vector.h:343

/usr/include/c++/4.0.2/bits/stl_vector.h:343:12255:beg:0x3edeffb
(gdb) bt
#0 0x03edeffb in std::vector<BlockData*, std::allocator<BlockData*>

::begin (this=0x9) at
/usr/lib/gcc/i386-redhat-linux/4.0.2/../../../../include/c++/4.0.2/bits/stl_vector.h:343

#1 0x03edf08d in std::vector<BlockData*, std::allocator<BlockData*>

::size (this=0x9) at
/usr/lib/gcc/i386-redhat-linux/4.0.2/../../../../include/c++/4.0.2/bits/stl_vector.h:403

#2 0x03edf0ca in GroupResult::size (this=0x1) at Result.h:66
#3 0x03f11e98 in PageBreaker::handleOverLap (this=0xbf97a63c) at
PageBreaker.cpp:274

Looks to me like the Result object itself is not valid. You also seem to be
mixing up Result and GroupResult here somewhere. Without more code, it's
impossible to tell what's actually going on, but the values shown above for
"this" in both Result and GroupResult definitely look wrong. Check the
actual instance(s) of the variable(s) containing _bdl, and I suspect you'll
find the problem.

-Howard