Thread: seg fault from std::list.push_back()

Hello,

I'm a C++ newbie and having a hard time figuring out this bug.

I am basically doing the following thing:

Code:

std::vector< std::list<int> > x;

x = std::vector< std::list<int> > (n);

for (int i = 0; i < n; i++)
  for (int r = 0; r < m[i]; r++)
    x[i].push_back(r);

The initialization of vector was done alright.

Then, I sometimes see segmentation fault in the middle of the double "for" loops, i.e. from push_back.

Does this mean the node allocator of list is touching some corrupted memory, and therefore a memory leak somewhere else?

btw, I have tried to catch the memory bug using valgrind and totalview from Etnus but they didn't find anything. Can you recommend any tips or useful tools for this?

- EJ

Originally Posted by The Brain

i think you can only push back 'list' objects into your vector. ('r' is of type int...)

The syntax looks alright to me. r is pushed back on the i'th list x[i].

- EJ

what is m[i]? and what is n? You're getting a seg fault probably because you for loop is trying to put a value in some space that is not allocated.

How big are 'n' and m[i]?

In my current case, n = 20 and m is an integer array of length n = 20 such that 1 <= m[i] <= 40 for all i in [0,20). Sorry I tried to abstract these facts since I knew they aren't the error factors.

instead of

Code:

x[i].push_back(r);

try

Code:

x.at(i).push_back(r);

that way you will get bounds checking where [] doesn't check bounds.

I have confirmed x[i] exist for all i in [0,n) through debugger.

Though I am using a vector of lists in the code, I think the problem purley orginates from std::list.push_back(). As far as I know, std::list.push_back() should always succeed only if memory can be allocated for the new node.

Tracing the memory error reveals that the error occurs from "allocate" down in the function called by push_back, as you can see below.

Code:

Invalid read of size 4

at 0x1B990642: std::__default_alloc_template<true, 0>::allocate(unsigned) (in /usr/lib/libstdc++.so.5.0.7)

by 0x8050890: std::__simple_alloc<std::_List_node<int>, std::__default_alloc_template<true, 0> >::allocate(unsigned) (stl_alloc.h:232)

by 0x8050863: std::_List_alloc_base<int, std::allocator<int>, true>::_M_get_node() (stl_list.h:277)

by 0x80517B2: std::list<int, std::allocator<int> >::_M_create_node(int const&) (stl_list.h:413)

by 0x8050A3F: std::list<int, std::allocator<int> >::insert(std::_List_iterator<int, int&, int*>, int const&) (list.tcc:89)

by 0x804F791: std::list<int, std::allocator<int> >::push_back(int const&) (stl_list.h:748)

Is this a memory leak?

The code posted looks fine, so it is likely caused by corruption elsewhere, or the actual code has some other error not seen here.

If you could try to pare down your actual program so that it is small enough to post here but still shows the error, then you might find the problem yourself or at least make it easier for us to help.

Daved is right. If you're working with a lot of arrays or vectors and you go past the array bounds segfaults usually come well after the actual error. I was recently doing something like that myself adn had lots of trouble with bugs like this one. When you say

I sometimes see segmentation fault in the middle of the double "for" loops

it already suggests the problem is not in the code you posted, otherwise you'd see a segfault every time. Perhaps you could run the program with differrent types of input so as to test differrent branches of your code, maybe this could help you pinpoint the source of the error.

Originally Posted by anykey

If you're working with a lot of arrays or vectors and you go past the array bounds segfaults usually come well after the actual error.

I agree with you. But one thing I don't understand is why this problem is not detected by numerous memory debugger. I tried LeakTrace, Valgrind, Totalview, and even insure++, all of which didn't generate any such error until before the actual seg fault happens.

I have just found a bug in the source and fixing it seems to have removed the problem so far, though I am expecting similar things can happen any time. I haven't understoo how that fixed bug generated seg fault though, since it allowed reading a vector over the bound but was not related to memory writing or allocation.

Thank you all for your help.

As indicated by Darryl, using at() instead of operator[], especially during debugging, can help identify the error by causing an exception immediately when you attempt to access an element outside the vector's bounds. You can then break into your code at that time to see how it happened. I'd suggest switching all your code to use at(), and once it is stable you can switch it back if you have performance issues caused by the change.