Segmentation faults in deque of user-defined pointers

Question

I have a deque<rect*> rects where rect is a user-defined class. When I try to insert a rect* into it, I get a segmentation fault. gdb traces the problem back to a function called __memmove_sse3() from my calling rects.insert(it,new rect([constructor parameters])); where it is a deque<rect*>::iterator. What could cause this error?

EDIT: here is a snippet of my code:

for(deque<rect*>::iterator it=rects.begin();it!=rects.end();++it)
        {
            rect r=*r1;
            rect r2=*(*it);
            if(!r2.there)
                continue;
            if(r.down>r2.up || r.up<r2.down || r.right<r2.left || r.left>r2.right)
                continue;
            if(r.left>r2.left)
                rects.insert(it,new rect(r2.left,r2.down,r.left,r2.up,r2.color));
            if(r.right<r2.right)
                rects.insert(it,new rect(r.right,r2.down,r2.right,r2.up,r2.color));
            if(r.up<r2.up)
                rects.insert(it,new rect(max(r.left,r2.left),r.up,min(r.right,r2.right),r2.up,r2.color));
            if(r.down>r2.down)
                rects.insert(it,new rect(max(r.left,r2.left),r2.down,min(r.right,r2.right),r.down,r2.color));
            r2.there=false;
        }

Iterator is invalidated maybe? – Pubby Dec 29 '12 at 18:09 — Pubby, Dec 29 '12 at 18:09

Nawaz · Accepted Answer · 2012-12-29T18:28:44.353

The problem is that you're inserting item to std::deque which invalidates the iterator which you're incrementing in the for loop:

The Standard (draft n3485) says in §23.3.3.4/1 (emphasize mine),

Effects: An insertion in the middle of the deque invalidates all the iterators and references to elements of the deque. An insertion at either end of the deque invalidates all the iterators to the deque, but has no effect on the validity of references to elements of the deque.

score 1 · Answer 2 · edited May 23 '17 at 11:56

Segfaults can come from any number of sources, and don't always manifest immediately. Chances are you're overflowing an array, using the stl containers in an invalid manner, or the like -- when you corrupt areas of memory you don't own that might be used for e.g. allocation accounting, it can make future allocations, frees, moves, or any other indirect accesses fail spectacularly.

Bringing out the big guns may help solve this quickly! You can use valgrind's memcheck module if you're on a system that will run valgrind, or you can use something like Application Verifier on Windows.

Your compiler or libraries may have standard library / STL debugging functionality -- if you're in an IDE, poke around to see what options you have available. For libstdc++ (often used with gcc/g++), you can look at the libstdc++ Debugging Support options.

Here's my earlier answer to a question about heap corruption which discusses such tools, and my list of reasons you might want to overload operator new and delete also has another list of tools. (Shameless self-promotion, here, but I think these are pretty good lists!)

Based on your code I'd say you're invalidating the loop iterator. From http://www.sgi.com/tech/stl/Deque.html:

The semantics of iterator invalidation for deque is as follows. Insert (including push_front and push_back) invalidates all iterators that refer to a deque. Erase in the middle of a deque invalidates all iterators that refer to the deque. Erase at the beginning or end of a deque (including pop_front and pop_back) invalidates an iterator only if it points to the erased element.

Segmentation faults in deque of user-defined pointers

2 Answers2