On Fri, Feb 26, 2010 at 9:25 AM, John (Eljay) Love-Jensen
<eljay@xxxxxxxxx> wrote:
> Hi everyone,
>
> Note: 32-bit application. ILP32, LL64.
>
> Isn't new[] supposed to throw std::bad_alloc in this situation?
>
> - - - - - - - - - - - - - - -
> int main()
> {
> int size = 0x4000000A;
> int* p = new int[size];
> for(int i = 0; i < size; ++i)
> {
> p[i] = i; // Crashes here.
> }
> }
> - - - - - - - - - - - - - - -
>
> The above loop is crashing sometime after p[9]. (On my system, it crashes on p[0x3FFAC]. Which is well after p[9] but long before p[0x40000009].)
>
> My assumption is that the problem for this 32-bit toy app where sizeof(int) is 4, is that 0x4000000A * 4 ==> 0x100000028, which gets (0x100000028 & 0xFFFFFFFF) sliced to 0x28.
>
> But, I presume, the size_t memory allocation request is being sliced to 0x28 before the new routine gets a chance to notice that the size * sizeof(type) is just too darn big. I also presume that the p[0x3FFAC] crash is just happenstance to do how the heap is allocated from the OS, and the code is trashing vast tracks of the heap before running off the end into SEGV land.
>
> My (naive?) expectations are that the new[] will throw a std::bad_alloc.
Yes. This is a long standing bug in g++.
There had been a recent patch from Florian to fix it (using
saturated arithmetic). I do not know whether it was accepted.
>
> Is this code undefined behavior, or working-as-expected, or bug in GCC's C++ compiler (4.0.1, in this case), or a PICNIC error?
>
> PICNIC - Program In Chair, Not In Computer
>
> If it is a bug in the GCC C++ compiler (4.0.1), has it since been fixed in a more recent version?
>
> Thanks,
> --Eljay
>
> # g++ crash.cpp
>
> # ./a.out
> Segmentation fault
>
> # g++ --version
> i686-apple-darwin9-g++-4.0.1 (GCC) 4.0.1 (Apple Inc. build 5490)
>
