On Fri, 2006-02-24 at 05:53 -0500, Josh Boyer wrote:
On Fri, 2006-02-24 at 10:45 +0000, David Woodhouse wrote:
>
> MACHINE_ALIGNMENT is the maximal alignment of various types, including
> 'long double'. That's recently changed from 8 bytes to 16. Could it be
> that malloc() or your own internal allocation routines are still
> returning chunks which are only 8-byte aligned?
Ah... that was the recent ABI change that caused rawhide to be respun a
bit ago, right?
It could be doing what you say. The code to generate the macro is
convoluted so I'll need to figure it out. If anyone cares, the code is
in the tla package at src/hackerlab/machine/gen-alignment.to-c (which
gets turned into a .c file at build time). And the code for the test
that's failing is in src/hackerlab/tests/array-tests/unit-ar.c.
When I find some time I'll try an figure it all out. In the meantime,
I'll just continue cursing tla ;).
I did some more digging and it turns out that malloc() _is_ returning
chunks that are only 8-byte aligned. See:
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=182742
for the details on tla itself, but I can reproduce 8-byte aligned
addresses with the trivial program below. From my understanding of the
recent ABI change, this shouldn't happen.
Jakub, do you want me to open a bug for this?
josh
[jwboyer@net2-102 ~]$ gcc -o malloc-check malloc-check.c
[jwboyer@net2-102 ~]$ ./malloc-check
foo is not 16-byte aligned: 10011008
[jwboyer@net2-102 ~]$
#include <stdio.h>
#include <stdlib.h>
int main(int argc, char **argv)
{
void *foo = NULL;
void *bar = NULL;
int i;
for (i = 0; i < 1000; i++) {
foo = malloc(360);
bar = malloc(360);
if ((unsigned long) foo & 0xf) {
printf("foo is not 16-byte aligned: %lx\n",
(unsigned long) foo);
return -1;
}
if ((unsigned long) bar & 0xf) {
printf("bar is not 16-byte aligned: %lx\n",
(unsigned long) bar);
return -1;
}
if (i % 150) {
free(foo);
free(bar);
foo = NULL;
bar = NULL;
}
}
return 0;
}