From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 14116 invoked by alias); 31 Oct 2011 15:24:03 -0000 Received: (qmail 14091 invoked by uid 22791); 31 Oct 2011 15:23:58 -0000 X-SWARE-Spam-Status: No, hits=-2.9 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 X-Spam-Check-By: sourceware.org Received: from localhost (HELO gcc.gnu.org) (127.0.0.1) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Mon, 31 Oct 2011 15:23:44 +0000 From: "simon at pushface dot org" To: gcc-bugs@gcc.gnu.org Subject: [Bug ada/50934] New: Allocated address for new controlled object is offset by 16 bytes Date: Mon, 31 Oct 2011 15:24:00 -0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: new X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: ada X-Bugzilla-Keywords: X-Bugzilla-Severity: major X-Bugzilla-Who: simon at pushface dot org X-Bugzilla-Status: UNCONFIRMED X-Bugzilla-Priority: P3 X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Changed-Fields: Message-ID: X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/ Auto-Submitted: auto-generated Content-Type: text/plain; charset="UTF-8" MIME-Version: 1.0 Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-bugs-owner@gcc.gnu.org X-SW-Source: 2011-10/txt/msg03218.txt.bz2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50934 Bug #: 50934 Summary: Allocated address for new controlled object is offset by 16 bytes Classification: Unclassified Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: major Priority: P3 Component: ada AssignedTo: unassigned@gcc.gnu.org ReportedBy: simon@pushface.org Created attachment 25674 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=25674 Demonstrator When I create a controlled type and an access type, the address returned by the 'new' is 16 bytes greater than the address determined within the allocator. I've attached an example which shows this with limited controlled, but it also happens with non-limited. I originally reported this to AdaCore as [K916-011 public] with regard to fixed-size storage pools on GNAT GPL 2011 on Mac OS X. Now, however, * GCC 4.7.0 fails on Mac OS X with both fixed-size and global pools, * GNAT GPL 2011 fails similarly on Debian 6 (32 bit), so I've taken the liberty of marking the Severity as 'major'. The attached code contains instrumented versions of the library allocators, and should be compiled "gnatmake -a allocation_test.adb". Running with $ gcc -v Using built-in specs. COLLECT_GCC=/opt/gcc-4.7-180524/bin/gcc COLLECT_LTO_WRAPPER=/opt/gcc-4.7-180524/libexec/gcc/x86_64-apple-darwin11/4.7.0/lto-wrapper Target: x86_64-apple-darwin11 Configured with: ../gcc-trunk-svn/configure CC='gcc -D_FORTIFY_SOURCE=0' --prefix=/opt/gcc-4.7-180524 --disable-multilib --enable-languages=c,ada --build=x86_64-apple-darwin11 Thread model: posix gcc version 4.7.0 20111026 (experimental) [trunk revision 180524] (GCC) I get $ ./allocation_test -------------------------------------------------- Allocation from fixed-size pool First_Free = 0 Pool_Size allocated 88 at 16#7FDD68400928#, The_Pool at 16#7FDD68400928# A ( 1) allocated at 16#7FDD68400938# or 140588913527096 First_Free = 0 Pool_Size allocated 88 at 16#7FDD68400970#, The_Pool at 16#7FDD68400928# A ( 2) allocated at 16#7FDD68400980# or 140588913527168 First_Free = 0 Pool_Size allocated 88 at 16#7FDD684009B8#, The_Pool at 16#7FDD68400928# A ( 3) allocated at 16#7FDD684009C8# or 140588913527240 First_Free = 0 Pool_Size allocated 88 at 16#7FDD68400A00#, The_Pool at 16#7FDD68400928# A ( 4) allocated at 16#7FDD68400A10# or 140588913527312 aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa? @h?( @h? bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb @h?p @h? cccccccccccccccccccccccccccccccccccccccccccccccc?#?? @h? dddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddd -------------------------------------------------- Allocation from global pool Pool_Global allocated 88 at 140588913527376 B ( 1) allocated at 16#7FDD68400A60# or 140588913527392 Pool_Global allocated 88 at 140588913527472 B ( 2) allocated at 16#7FDD68400AC0# or 140588913527488 Pool_Global allocated 88 at 140588913527568 B ( 3) allocated at 16#7FDD68400B20# or 140588913527584 Pool_Global allocated 88 at 140588913527664 B ( 4) allocated at 16#7FDD68400B80# or 140588913527680 aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb cccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccc dddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddd -------------------------------------------------- The corruption in the first section, the fixed-size storage pool, is obvious; there should be 4 lines, each containing 64 'a's, 'b's etc. The reason is to be seen in the trace output; for example, in the fixed-size section, Pool_Size allocated 88 at 16#7FDD68400928#, The_Pool at 16#7FDD68400928# A ( 1) allocated at 16#7FDD68400928# or 140588913527096 the internally allocated address is 16#7FDD68400928# but the value seen by the calling routine is 16#7FDD68400928#, 16#10# greater. In the default section, the corruption is less obvious, presumably because malloc() is allocating spare space anyway, but in the trace output Pool_Global allocated 88 at 140588913527376 B ( 1) allocated at 16#7FDD68400A60# or 140588913527392 the internal and external addresses are again off by 16 (I had to use GNAT.IO internally to avoid elaboration circularity).