From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,FREEMAIL_FROM autolearn=unavailable autolearn_force=no version=3.4.4 X-Received: by 10.224.173.4 with SMTP id n4mr13225707qaz.3.1376528775188; Wed, 14 Aug 2013 18:06:15 -0700 (PDT) X-Received: by 10.50.124.66 with SMTP id mg2mr13510igb.16.1376528775140; Wed, 14 Aug 2013 18:06:15 -0700 (PDT) Path: eternal-september.org!reader01.eternal-september.org!reader02.eternal-september.org!news.eternal-september.org!news.eternal-september.org!news.eternal-september.org!feeder.eternal-september.org!usenet.blueworldhosting.com!feeder02.blueworldhosting.com!npeer01.iad.highwinds-media.com!news.highwinds-media.com!feed-me.highwinds-media.com!fx3no2517386qab.0!news-out.google.com!he10ni1979qab.0!nntp.google.com!fx3no2517383qab.0!postnews.google.com!glegroupsg2000goo.googlegroups.com!not-for-mail Newsgroups: comp.lang.ada Date: Wed, 14 Aug 2013 18:06:14 -0700 (PDT) In-Reply-To: <12ebc074-b545-4528-af28-48864d90d049@googlegroups.com> Complaints-To: groups-abuse@google.com Injection-Info: glegroupsg2000goo.googlegroups.com; posting-host=59.16.25.168; posting-account=AHt6zAoAAABQOfQrPx9x4er-wkJ_JuMM NNTP-Posting-Host: 59.16.25.168 References: <9de9c3bf-c4c5-466f-a8cd-fca992daecbe@googlegroups.com> <20130814213210.5ebf41e7@lufsen.sandat.dyndns.org> <12ebc074-b545-4528-af28-48864d90d049@googlegroups.com> User-Agent: G2/1.0 MIME-Version: 1.0 Message-ID: <0a76f2be-4254-4641-8fa9-844aebacc545@googlegroups.com> Subject: Re: GNAT Allocation of a very large record From: Hyung-Hwan Chung Injection-Date: Thu, 15 Aug 2013 01:06:15 +0000 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Received-Bytes: 5682 Xref: news.eternal-september.org comp.lang.ada:16861 Date: 2013-08-14T18:06:14-07:00 List-Id: On Thursday, August 15, 2013 5:08:32 AM UTC+9, Anh Vo wrote: > On Wednesday, August 14, 2013 12:32:10 PM UTC-7, Per Sandberg wrote: >=20 > > Tried 4 different GCC:s and one failed: > >=20 > > gcc 4.4.7 20120313 (Red Hat 4.4.7-3) (GCC) x86 ok=20 > > gcc 4.6.3 20120306 (Red Hat 4.6.3-2) (GCC) x86_64 ok=20 > > gcc 4.7.3 20130318 for GNAT Pro 7.2.0w (20130317) (GCC) x86_64 ok=20 > > gcc 4.4.5 (Debian 4.4.5-8) arm (raspberry-pi) fail >=20 > It works fine with GNAT-GPL-2013 on Windows and GNATPro 7.1.1 on Red Hat = x86. > =20 > A. Vo I tried gcc 4.4.7 20120313 (Red Hat 4.4.7-2) (GCC) x86_64 and it seemed to = work find originally. Soon later, I wanted to confirm this at a slightly l= ower-level and realized that it gave me the illusion that it worked. It raised the STORAGE_ERROR exception. But the key here is that how it was = raised. Strace reveals that there was a segmentation fault. You can guess that the = program catches SIGSEGV from rt_sigaction (SIGSEGV,...) at the beginning. $ strace ./x1 ---- rt_sigaction(SIGSEGV, {0x41ac90, [], SA_RESTORER|SA_STACK|SA_RESTART|SA_NOD= EFER|SA_SIGINFO, 0x7fd6ba93a920}, NULL, 8) =3D 0 fstat(2, {st_mode=3DS_IFREG|0664, st_size=3D2182, ...}) =3D 0 fstat(0, {st_mode=3DS_IFCHR|0620, st_rdev=3Dmakedev(4, 2), ...}) =3D 0 fstat(1, {st_mode=3DS_IFCHR|0620, st_rdev=3Dmakedev(4, 2), ...}) =3D 0 brk(0) =3D 0xd23000 brk(0xd44000) =3D 0xd44000 write(1, "1. Kind: POINTER_OBJECT Size: 1"..., 34) =3D 34 --- SIGSEGV (Segmentation fault) @ 0 (0) --- brk(0xd65000) =3D 0xd65000 write(1, "2. Allocation Failed\n", 21) =3D 21 exit_group(0) =3D ? =20 Ltrace reveals that the second attempt to 'new' that translated to malloc e= ventually requested 16 bytes only. You can also print the Pointer_Object_Re= cord'Max_Size_In_Storage_Elements from within the program. I used ltrace to= see the real value passed to the malloc function. This comes down to the = overflow/wrap-around issue. $ ltrace ./x1 -- -- malloc(104) =3D 0x18cd010 memcpy(0x7fff0c80a6d0, "1. Kind: ", 9) =3D 0x7fff0c80a6d0 memcpy(0x7fff0c80a6d9, "POINTER_OBJECT", 14) =3D 0x7fff0c80a6d9 memcpy(0x7fff0c80a6e7, " Size: ", 7) =3D 0x7fff0c80a6e7 memcpy(0x7fff0c80a6ee, " 10", 3) =3D 0x7fff0c80a6ee memcpy(0x6302a8, "1. Kind: POINTER_OBJECT Size: 1"..., 33) =3D 0x6302a8 memcpy(0x7fff0c80a790, "1. Kind: POINTER_OBJECT Size: 1"..., 33) =3D 0x7ff= f0c80a790 fwrite("1. Kind: POINTER_OBJECT Size: 1"..., 34, 1, 0x7f630f8ad780) =3D 1 malloc(16) =3D 0x18cd080 --- SIGSEGV (Segmentation fault) --- malloc(64) =3D 0x18ee010 -- -- The assembly listing for the 'new' allocation part is shown here. It was pr= oduced with the command 'gcc -S x1.adb'. You can see that it initializes th= e record after memory allocation. I assume that __gnat_malloc contains the = check for the actual malloc failure. For this case, malloc was given 16 so = I'm sure it has reached the part after 'call __gnat_malloc'. The line 'movq= $0, 16(%rax)' violates the memory access for the first time as it's access= ing beyond the 16 byte block allocated. I believe that the line is for 'Cla= ss =3D> Null'. If it carried on, it would execute the code after the label = .L53 starting from a few lines above it in a loop for 'Pointer_Slot =3D> (o= thers =3D> null)'. That would also violate the memory access. ---- call __gnat_malloc movb $0, (%rax) movq -840(%rbp), %rdx movq %rdx, 8(%rax) movzbl 1(%rax), %edx andl $-8, %edx movb %dl, 1(%rax) movzbl 1(%rax), %edx andl $-9, %edx movb %dl, 1(%rax) movzbl 1(%rax), %edx andl $15, %edx movb %dl, 1(%rax) movq $0, 16(%rax)=20 movq -840(%rbp), %rdx movq %rdx, %rcx testq %rcx, %rcx jle .L52 movl $1, %edx .L53: movq %rdx, %rbx addq $1, %rbx movq $0, 8(%rax,%rbx,8) cmpq %rdx, %rcx je .L52 addq $1, %rdx jmp .L53 ---- Valgrind fails more miserably with this program. Any comments? Thanks again, Hyung-Hwan