public inbox for gcc-bugs@sourceware.org help / color / mirror / Atom feed
From: "simon at pushface dot org" <gcc-bugzilla@gcc.gnu.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 [thread overview] Message-ID: <bug-50934-4@http.gcc.gnu.org/bugzilla/> (raw) 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).
next reply other threads:[~2011-10-31 15:24 UTC|newest] Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top 2011-10-31 15:24 simon at pushface dot org [this message] 2011-11-02 20:58 ` [Bug ada/50934] " simon at pushface dot org 2011-11-02 21:03 ` [Bug ada/50934] Attribute Max_Size_In_Storage_Elements is wrong for controlled types simon at pushface dot org 2011-11-03 8:14 ` simon at pushface dot org 2011-11-03 17:34 ` simon at pushface dot org 2012-05-27 11:00 ` simon at pushface dot org 2012-05-27 11:20 ` ebotcazou at gcc dot gnu.org
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=bug-50934-4@http.gcc.gnu.org/bugzilla/ \ --to=gcc-bugzilla@gcc.gnu.org \ --cc=gcc-bugs@gcc.gnu.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).