Re: [boost] Bug with gcc and array

Subject: Re: [boost] Bug with gcc and array
From: Giovanni Piero Deretta (gpderetta_at_[hidden])
Date: 2008-11-24 08:50:02

On Mon, Nov 24, 2008 at 2:01 PM, Andreas Klein <klein_at_[hidden]> wrote:
> Dear developers.
>
> I send this both to the boost and the gcc developers.
>
> I have found a strange limitation for the size of an array. The error
> is the same both for boost 1.36 and for the array in gcc 4.3.2 (and in
> the gcc 4.4 snapshot I use). I am almost sure that it is a bug of gcc
> and not of the array implementation.
>
> Here is the code.
>
> #include<array>
> using namespace std;
>
>
> int main () {
>  array<unsigned int, (1<<22)> a; // Create a big array
>
>  a[(1<<22)-13]=0;  // This give a segmantation fault
> }
>

There is no bug. boost::array does no dynamic memory allocation, so
you are creating a circa 30 MB array on the stack. This is enough to
blow the stack size limit on most OSs.

> In contrast a C-array works fine.
>
> int main () {
>  unsigned int  a[1<<22];
>
>  a[(1<<22)-13]=0;
> }
>
> Since the naturale implementation of the array class is just a wrapper
> around the C-style array this is very strange.

Sheer luck probably. You have gone beyond an implementation defined
limit and it is UB. In fact using a C -style array might (or not) have
blown the stack in the same way.

>
> I tryed to track down the bug. You use the following implementation:
>

[ Sniped: code using new instead of a member array ]

> It seams that this resolves the bug.

But you lose some nice properties of boost::array: no dynamic
allocation and aggregate initialization. At this point you might as
well use std::vector.

> But I can not explain why.
> I tested the code with the intel compiler and it works fine for both
> implementations. So it seams that it is a gcc bug, that the first
> solution do not work. What happens here?
>

It is not a bug of gcc (although a warning would have been
appreciated), just a manifestation of UB. It might be that the intel
compiler sets the stack size limit higher, it disables stack overflow
checking or simply you are just being lucky (or unlucky, depends on
how you see it) and UB is not showing up as an hard crash.

Morale: do not stack allocate huge objects.

-- 
gpd