segfault and valarray

[dm215]

So here is some sample code:

#include<valarray>

int main()
{
    std::valarray<double> vec(10);

    for (size_t i=0; i<11; i++)
        vec[i] = 1.0;

    std::valarray<double> vec2(vec);

    return 0;
}

So, in a situation similar to this one, I am segfauting, but not in the loop, rather in the constructor call after the loop. Question is, is this behavior expected generally, or is it unique to valarray, or something else? The strange thing is, even if I re-write the code to construct vec2 based on vec.size() instead of vec itself, the segfault still happens at the constructor for vec2. This is even when the debugger is showing a correct size (10) for vec.size().

I spent some considerable time looking for a bug this afternoon, based on this type of mistake. Just hoping to get some philosophical satisfaction out of it!

[Ancient Dragon]

That for loop will iterate 11 times, not 10. 0, 1, 2, 3, ... 10 are 11 numbers. Either increase the size of vec to 11 or correct the loop.

[dm215]

That for loop will iterate 11 times, not 10. 0, 1, 2, 3, ... 10 are 11 numbers. Either increase the size of vec to 11 or correct the loop.

Yes, that's right -- sorry, I should have been clearer. I know that the loop creates an overflow. My question regards the point in the execution where a segfault occurs. In one particular case, the loop executes no problem (at least according to the debugger, gdb in this case), but when I later call a constructor based on "vec" (as shown in the sample) I get a segfault. My question remains, why?

[Ancient Dragon]

fix the overflow first then rerun your program. Overflows scribble all over memory and can cause problems in the most unexpected places.

[thekashyap]

In one particular case, the loop executes no problem (at least according to the debugger, gdb in this case)

Yeah, that's coz you're unlucky.. :). Simple thing is you shouldn't write code that overflows (particularly when you know it).

but when I later call a constructor based on "vec" (as shown in the sample) I get a segfault. My question remains, why?

Well, this time you got lucky so you got SEGV. Imagine what would've happened if it worked at this time also and finally when your product reached customer (or the prof in your project viva) and then it does..

If you press for a reason well, i would guess that between the time when first loop was executed and second is executed, you've allocated some new memory (for vec2), and this could[should] be overwriting vec's 11th element's memory.

[dm215]

Okay, thanks everybody. I know that I have to fix the overflows -- actually, they were already fixed before I posted this and things are running fine. But it took me an entire half-day to track it down, since the segfault occurred down the line from where the overflow actually was, so I was just trying to get some insight as to why/how this happens in case it might be useful in tracking down future bugs.

[thekashyap]

But it took me an entire half-day to track it down, since the segfault occurred down the line from where the overflow actually was

Tell me abt it.. :)
Guess everyone faces this some time or the other while they learn programming..
That's teh reason I used words "lucky/unlucky".. may be after a few years your hand will get used to not making ArrayOutOfBound errors..