Debugging a Segmentation Fault in C++ STL code

[silverburgh.meryl]

Hi,

I have a C++ problem which uses STL containers and algorithm and it has
a segmentation fault under some condition.

Here is a back trace from gdb. Is it possible to tell what is wrong
from the trace? I know which method is crashing (MyHandler.cpp: 133),
but I don't know why.

Thanks for any help.

#0 0x008173a3 in memmove () from /lib/libc.so.6
#1 0x05d6eace in std::__copy<tru e,
std::random_acc ess_iterator_ta g>::copy<A*> (__first=0xf762 b070,
__last=0x10, __result=0x0) at stl_algobase.h: 300
#2 0x05d6eafb in std::__copy_aux <A**, A**> (__first=0x89d4 f90,
__last=0x89d4fa 0, __result=0x0) at stl_algobase.h: 317
#3 0x05d6eb43 in std::__copy_nor mal<true,
true>::copy_n<_ _gnu_cxx::__nor mal_iterator<A* *, std::vector<A*,
std::allocator< A*> > >, __gnu_cxx::__no rmal_iterator<A **,
std::vector<A*, std::allocator< A*> > > > (__first={_M_cu rrent =
0x89d4f90}, __last={_M_curr ent = 0x89d4fa0}, __result={_M_cu rrent =
0x0}) at stl_algobase.h: 354
#4 0x05d6eb89 in std::copy<__gnu _cxx::__normal_ iterator<A**,
std::vector<A*, std::allocator< A*> > >,
__gnu_cxx::__no rmal_iterator<A **, std::vector<A*, std::allocator< A*> >

(__first={_M_cu rrent = 0x89d4f90}, __last={_M_curr ent = 0x89d4fa0}, __result={_M_cu rrent = 0x0}) at stl_algobase.h: 387

#5 0x05d6fa9d in do_divide::oper ator() (this=0xbf91985 c,
element=0x8ccea 30) at MyHandler.cpp:1 33

[Mike Wahler]

<si************ ***@gmail.com> wrote in message
news:11******** *************@g 44g2000cwa.goog legroups.com...

Hi,

I have a C++ problem which uses STL containers and algorithm and it has
a segmentation fault under some condition.

Here is a back trace from gdb. Is it possible to tell what is wrong
from the trace? I know which method is crashing (MyHandler.cpp: 133),
but I don't know why.
Without seeing your code, we can only guess. Try to assemble
a small, compilable example that still produces the undesired
behavior and post it here.

Having said that, I'll go ahead and take a guess:
#0 0x008173a3 in memmove () from /lib/libc.so.6
#1 0x05d6eace in std::__copy<tru e,
std::random_acc ess_iterator_ta g>::copy<A*> (__first=0xf762 b070,
__last=0x10, __result=0x0) at stl_algobase.h: 300
#2 0x05d6eafb in std::__copy_aux <A**, A**> (__first=0x89d4 f90,
__last=0x89d4fa 0, __result=0x0) at stl_algobase.h: 317

The diagnostic text you've posted refers to 'std::copy()'.
Note that this function copies data from one storage location to
another, *but does not allocate any storage, you must do this
yourself*. E.g.:

std::vector<int > v1(10); // vector of ten zero-initialized integers
std::vector<int > v2; // *empty* vector of integers

std::copy(v1.be gin(), v1.end(), v2.begin()); // ERROR, no place to write

If this is indeed your problem, look up 'insert_iterato r',
'back_insert_it erator', 'back_inserter' , etc. These constructs
will create storage for 'copy' to write to. Alternatively, look
at vector::resize( ), which will add (or subtract) the necessary number
of elements to make the vector of the indicated size. (If it adds
elements, they will be default-initialized).

But again, this is only my best guess given the limited
information you provided.

-Mike

[TB]

si************* **@gmail.com sade:

Hi,

I have a C++ problem which uses STL containers and algorithm and it has
a segmentation fault under some condition.

Here is a back trace from gdb. Is it possible to tell what is wrong
from the trace? I know which method is crashing (MyHandler.cpp: 133),
but I don't know why.

Thanks for any help.

Let me reorder the error messages a bit:
#5 0x05d6fa9d in do_divide::oper ator() (this=0xbf91985 c,
element=0x8ccea 30) at MyHandler.cpp:1 33
In do_divide::oper ator() you're apparently using std::copy().
#4 0x05d6eb89 in std::copy<__gnu _cxx::__normal_ iterator<A**,
std::vector<A*, std::allocator< A*> > >,
__gnu_cxx::__no rmal_iterator<A **, std::vector<A*, std::allocator< A*>

(__first={_M_cu rrent = 0x89d4f90}, __last={_M_curr ent = 0x89d4fa0},
__result={_M_cu rrent = 0x0}) at stl_algobase.h: 387

The quasi-prototype for std::copy() is:
OutputIterator copy(InputItera tor __first, InputIterator __last,
OutputIterator __result)

Now, look at what value '__result' has in your error message:
__last={_M_curr ent = 0x0}

I'd guess you're passing an invalid iterator (containing a null pointer
in this case) to std::copy() which further down in memmove() causes
your segfault.
#0 0x008173a3 in memmove () from /lib/libc.so.6
#1 0x05d6eace in std::__copy<tru e,
std::random_acc ess_iterator_ta g>::copy<A*> (__first=0xf762 b070,
__last=0x10, __result=0x0) at stl_algobase.h: 300
#2 0x05d6eafb in std::__copy_aux <A**, A**> (__first=0x89d4 f90,
__last=0x89d4fa 0, __result=0x0) at stl_algobase.h: 317
#3 0x05d6eb43 in std::__copy_nor mal<true,
true>::copy_n<_ _gnu_cxx::__nor mal_iterator<A* *, std::vector<A*,
std::allocator< A*> > >, __gnu_cxx::__no rmal_iterator<A **,
std::vector<A*, std::allocator< A*> > > > (__first={_M_cu rrent =
0x89d4f90}, __last={_M_curr ent = 0x89d4fa0}, __result={_M_cu rrent =
0x0}) at stl_algobase.h: 354

Just watch that nasty bug propagate down the call stack.

--
TB @ SWEDEN

[TB]

TB sade:

si************* **@gmail.com sade:

Hi,

I have a C++ problem which uses STL containers and algorithm and it has
a segmentation fault under some condition.

Here is a back trace from gdb. Is it possible to tell what is wrong
from the trace? I know which method is crashing (MyHandler.cpp: 133),
but I don't know why.

Thanks for any help.

Let me reorder the error messages a bit:

> #5 0x05d6fa9d in do_divide::oper ator() (this=0xbf91985 c,
> element=0x8ccea 30) at MyHandler.cpp:1 33

In do_divide::oper ator() you're apparently using std::copy().

> #4 0x05d6eb89 in std::copy<__gnu _cxx::__normal_ iterator<A**,
> std::vector<A*, std::allocator< A*> > >,
> __gnu_cxx::__no rmal_iterator<A **, std::vector<A*, std::allocator< A*>

> > >

> (__first={_M_cu rrent = 0x89d4f90}, __last={_M_curr ent = 0x89d4fa0},
> __result={_M_cu rrent = 0x0}) at stl_algobase.h: 387

The quasi-prototype for std::copy() is:
OutputIterator copy(InputItera tor __first, InputIterator __last,
OutputIterator __result)

Now, look at what value '__result' has in your error message:
__last={_M_curr ent = 0x0}

It should of course read

__result={_M_cu rrent = 0x0}

not

__last={_M_curr ent = 0x0}

--
TB @ SWEDEN

[silverburgh.meryl]

That is indeed my problem:

std::vector<int> v1(10); // vector of ten zero-initialized integers
std::vector<int> v2;     // *empty* vector of integers
 
std::copy(v1.begin(), v1.end(), v2.begin());  // ERROR, no place to
write
 

How can I make sure v2 has enough size before calling 'copy'?

[Gavin Deane]

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

That is indeed my problem:

 std::vector<int> v1(10); // vector of ten zero-initialized integers
 std::vector<int> v2;     // *empty* vector of integers

 std::copy(v1.begin(), v1.end(), v2.begin());  // ERROR, no place to
 write
 

How can I make sure v2 has enough size before calling 'copy'?

Create it that big to start with

std::vector<int > v2(10);

or create it then call resize

std::vector<int > v2;
v2.resize(10);

Another option which has v2 grow as required (instead of setting it to
the right size to start with) is to pass a back insert iterator for v2
to std::copy.

Gavin Deane

[Thomas Tutone]

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

That is indeed my problem:

 std::vector<int> v1(10); // vector of ten zero-initialized integers
 std::vector<int> v2;     // *empty* vector of integers

 std::copy(v1.begin(), v1.end(), v2.begin());  // ERROR, no place to
 write
 

How can I make sure v2 has enough size before calling 'copy'?
Mike Wahler already anticipated your question and answered it. Here's
his response again:
If this is indeed your problem, look up 'insert_iterato r',
'back_insert_it erator', 'back_inserter' , etc. These constructs
will create storage for 'copy' to write to. Alternatively, look
at vector::resize( ), which will add (or subtract) the necessary number
of elements to make the vector of the indicated size. (If it adds
elements, they will be default-initialized).

Best regards,

Tom

[TB]

si************* **@gmail.com sade:

That is indeed my problem:

 std::vector<int> v1(10); // vector of ten zero-initialized integers
 std::vector<int> v2;     // *empty* vector of integers

 std::copy(v1.begin(), v1.end(), v2.begin());  // ERROR, no place to
 write
 

How can I make sure v2 has enough size before calling 'copy'?

One pratical way to solve this is to use a back inserter:

#include <iterator>
std::copy(v1.be gin(), v1.end(), std::back_inser ter(v2));

The inserter will call push_back() on the container for
each new element, thus relieving you of making sure
the container is preallocated to a certain size.

Another way is to resize the vector to the same size
of the source container:

v2.resize(v1.si ze());

--
TB @ SWEDEN