From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 16150 invoked by alias); 26 Feb 2010 15:26:17 -0000 Received: (qmail 16108 invoked by uid 22791); 26 Feb 2010 15:26:16 -0000 X-SWARE-Spam-Status: No, hits=-2.4 required=5.0 tests=AWL,BAYES_00 X-Spam-Check-By: sourceware.org Received: from exprod6og103.obsmtp.com (HELO exprod6og103.obsmtp.com) (64.18.1.185) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Fri, 26 Feb 2010 15:26:09 +0000 Received: from source ([192.150.8.22]) by exprod6ob103.postini.com ([64.18.5.12]) with SMTP ID DSNKS4foDmEAde158D+j1lVm3BJ26sKx97MY@postini.com; Fri, 26 Feb 2010 07:26:09 PST Received: from inner-relay-3.eur.adobe.com (inner-relay-3b [10.128.4.236]) by outbound-smtp-2.corp.adobe.com (8.12.10/8.12.10) with ESMTP id o1QFQ4s5004406 for ; Fri, 26 Feb 2010 07:26:04 -0800 (PST) Received: from nacas02.corp.adobe.com (nacas02.corp.adobe.com [10.8.189.100]) by inner-relay-3.eur.adobe.com (8.12.10/8.12.9) with ESMTP id o1QFQ17p017602 for ; Fri, 26 Feb 2010 07:26:03 -0800 (PST) Received: from excas03.corp.adobe.com (10.8.189.123) by nacas02.corp.adobe.com (10.8.189.100) with Microsoft SMTP Server (TLS) id 8.1.375.2; Fri, 26 Feb 2010 07:26:00 -0800 Received: from nambxv01a.corp.adobe.com ([10.8.189.95]) by excas03.corp.adobe.com ([10.8.189.123]) with mapi; Fri, 26 Feb 2010 07:26:00 -0800 From: "John (Eljay) Love-Jensen" To: "gcc-help@gcc.gnu.org" Date: Fri, 26 Feb 2010 19:42:00 -0000 Subject: Isn't new[] supposed to throw std::bad_alloc in this situation? Message-ID: <4B7A6CC9992C4E4FB188D02872C90A6B134EC8@nambxv01a.corp.adobe.com> Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-IsSubscribed: yes Mailing-List: contact gcc-help-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-help-owner@gcc.gnu.org X-SW-Source: 2010-02/txt/msg00354.txt.bz2 Hi everyone, Note: 32-bit application. ILP32, LL64. Isn't new[] supposed to throw std::bad_alloc in this situation? - - - - - - - - - - - - - - - int main() { int size =3D 0x4000000A; int* p =3D new int[size]; for(int i =3D 0; i < size; ++i) { p[i] =3D 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 =3D=3D> 0x100000028, which gets (0x100000028 = & 0xFFFFFFFF) sliced to 0x28. But, I presume, the size_t memory allocation request is being sliced to 0x2= 8 before the new routine gets a chance to notice that the size * sizeof(typ= e) 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 t= rashing 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. 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)