clang expects memory aligned on 16 bytes, but pymalloc aligns to 8 bytes #80799

vstinner · 2019-04-12T17:36:22Z

BPO	36618
Nosy	@gpshead, @vstinner, @serge-sans-paille, @pablogsal
PRs	bpo-36618: Add -fmax-type-align=8 flag for clang #12809 bpo-36618: Don't add -fmax-type-align flag to old clang #12811 bpo-36618: Don't add -fmax-type-align=8 flag for clang #13320

^{Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.}

Show more details

GitHub fields:

assignee = None
closed_at = <Date 2019-05-14.17:31:20.752>
created_at = <Date 2019-04-12.17:36:22.152>
labels = ['build', '3.8']
title = 'clang expects memory aligned on 16 bytes, but pymalloc aligns to 8 bytes'
updated_at = <Date 2019-05-14.17:31:20.749>
user = 'https://github.com/vstinner'

bugs.python.org fields:

activity = <Date 2019-05-14.17:31:20.749>
actor = 'vstinner'
assignee = 'none'
closed = True
closed_date = <Date 2019-05-14.17:31:20.752>
closer = 'vstinner'
components = ['Build']
creation = <Date 2019-04-12.17:36:22.152>
creator = 'vstinner'
dependencies = []
files = []
hgrepos = []
issue_num = 36618
keywords = ['patch']
message_count = 17.0
messages = ['340087', '340100', '340106', '340108', '340116', '340126', '340128', '340129', '340130', '340131', '340261', '340279', '340280', '340281', '340322', '342490', '342491']
nosy_count = 5.0
nosy_names = ['gregory.p.smith', 'vstinner', 'fweimer', 'serge-sans-paille', 'pablogsal']
pr_nums = ['12809', '12811', '13320']
priority = 'normal'
resolution = 'fixed'
stage = 'resolved'
status = 'closed'
superseder = None
type = None
url = 'https://bugs.python.org/issue36618'
versions = ['Python 3.8']

vstinner · 2019-04-12T17:36:22Z

On x86-64, clang -O3 compiles the following function:

PyCArgObject *
PyCArgObject_new(void)
{
    PyCArgObject *p;
    p = PyObject_New(PyCArgObject, &PyCArg_Type);
    if (p == NULL)
        return NULL;
    p->pffi_type = NULL;
    p->tag = '\0';
    p->obj = NULL;
    memset(&p->value, 0, sizeof(p->value));
    return p;
}

like that:

0x00007fffe9c6acb0 <+0>: push rax
0x00007fffe9c6acb1 <+1>: mov rdi,QWORD PTR [rip+0xe308] # 0x7fffe9c78fc0
0x00007fffe9c6acb8 <+8>: call 0x7fffe9c5e8a0 <_PyObject_New@plt>
0x00007fffe9c6acbd <+13>: test rax,rax
0x00007fffe9c6acc0 <+16>: je 0x7fffe9c6acdf <PyCArgObject_new+47>
0x00007fffe9c6acc2 <+18>: mov QWORD PTR [rax+0x20],0x0
0x00007fffe9c6acca <+26>: mov BYTE PTR [rax+0x28],0x0
0x00007fffe9c6acce <+30>: xorps xmm0,xmm0
0x00007fffe9c6acd1 <+33>: movaps XMMWORD PTR [rax+0x30],xmm0
0x00007fffe9c6acd5 <+37>: mov QWORD PTR [rax+0x40],0x0
0x00007fffe9c6acdd <+45>: pop rcx
0x00007fffe9c6acde <+46>: ret
0x00007fffe9c6acdf <+47>: xor eax,eax
0x00007fffe9c6ace1 <+49>: pop rcx
0x00007fffe9c6ace2 <+50>: ret

The problem is that movaps requires the memory address to be aligned on 16 bytes, whereas PyObject_New() uses pymalloc allocator (the requested size is 80 bytes, pymalloc supports allocations up to 512 bytes) and pymalloc only provides alignment on 8 bytes.

If PyObject_New() returns an address not aligned on 16 bytes, PyCArgObject_new() crash immediately with a segmentation fault (SIGSEGV).

CPython must be compiled using -fmax-type-align=8 to avoid such alignment crash. Using this compiler flag, clag emits expected machine code:

0x00007fffe9caacb0 <+0>: push rax
0x00007fffe9caacb1 <+1>: mov rdi,QWORD PTR [rip+0xe308] # 0x7fffe9cb8fc0
0x00007fffe9caacb8 <+8>: call 0x7fffe9c9e8a0 <_PyObject_New@plt>
0x00007fffe9caacbd <+13>: test rax,rax
0x00007fffe9caacc0 <+16>: je 0x7fffe9caacdf <PyCArgObject_new+47>
0x00007fffe9caacc2 <+18>: mov QWORD PTR [rax+0x20],0x0
0x00007fffe9caacca <+26>: mov BYTE PTR [rax+0x28],0x0
0x00007fffe9caacce <+30>: xorps xmm0,xmm0
0x00007fffe9caacd1 <+33>: movups XMMWORD PTR [rax+0x30],xmm0
0x00007fffe9caacd5 <+37>: mov QWORD PTR [rax+0x40],0x0
0x00007fffe9caacdd <+45>: pop rcx
0x00007fffe9caacde <+46>: ret
0x00007fffe9caacdf <+47>: xor eax,eax
0x00007fffe9caace1 <+49>: pop rcx
0x00007fffe9caace2 <+50>: ret

"movaps" instruction becomes "movups" instruction: "a" stands for "aligned" in movaps, whereas "u" stands for "unaligned" in movups.

vstinner · 2019-04-12T19:27:49Z

New changeset 23a683a by Victor Stinner in branch 'master':
bpo-36618: Add -fmax-type-align=8 flag for clang (GH-12809)
23a683a

vstinner · 2019-04-12T20:07:12Z

I merged a "workaround" in the master branch. Python 2.7 and 3.7 are also affected, but I prefer to wait to see if the change goes through buildbots.

The real fix would be to modify pymalloc to use 16-byte alignement, but that's a more complex issue :-)

vstinner · 2019-04-12T20:10:59Z

Note to myself: "Sadly, the flag must be expected to CFLAGS and not just CFLAGS_NODIST, ..."

It should be "Sadly, the flag must be *set* to CFLAGS and not just CFLAGS_NODIST, ..." :-( I should fix the NEWS entry.

vstinner · 2019-04-12T22:01:30Z

Oh, it seems like the change broke the FreeBSD 10 buildbot :-(

https://buildbot.python.org/all/#/builders/167/builds/769

...
checking for makedev... no
checking for le64toh... no
checking for mode_t... no
checking for off_t... no
checking for pid_t... no
checking for size_t... no
checking for uid_t in sys/types.h... yes
checking for ssize_t... no
checking for __uint128_t... no
checking size of int... 0
checking size of long... 0
checking size of long long... 0
checking size of void *... 0
checking size of short... 0
checking size of float... 0
checking size of double... 0
checking size of fpos_t... 0
checking size of size_t... 0
checking size of pid_t... 0
checking size of uintptr_t... 0
checking for long double... yes
configure: error: in /usr/home/buildbot/python/3.x.koobs-freebsd10.nondebug/build': configure: error: cannot compute sizeof (long double) See config.log' for more details

--

On the previous build, the output looked fine:

https://buildbot.python.org/all/#/builders/167/builds/768

...
checking size of int... 4
checking size of long... 8
checking size of long long... 8
checking size of void *... 8
checking size of short... 2
checking size of float... 4
checking size of double... 8
checking size of fpos_t... 8
checking size of size_t... 8
checking size of pid_t... 4
checking size of uintptr_t... 8
checking for long double... yes
checking size of long double... 16

pythoninfo:

CC.version: FreeBSD clang version 3.4.1 (tags/RELEASE_34/dot1-final 208032) 20140512
os.uname: posix.uname_result(sysname='FreeBSD', nodename='10-STABLE-amd64.elysium', release='10.4-STABLE', version='FreeBSD 10.4-STABLE #1 r337021: Wed Aug 1 15:12:48 AEST 2018 root@10-STABLE-amd64.elysium:/usr/obj/usr/src/sys/GENERIC', machine='amd64')
platform.platform: FreeBSD-10.4-STABLE-amd64-64bit-ELF

vstinner · 2019-04-12T22:37:48Z

See also:

bpo-27987: obmalloc's 8-byte alignment causes undefined behavior
bpo-18835: Add PyMem_AlignedAlloc()
bpo-31912: PyMem_Malloc() should guarantee alignof(max_align_t)

gpshead · 2019-04-12T22:49:21Z

Even if you check for -fmax-type-align compiler support at configure time, there is a potential problem:

Nothing guarantees that extension modules are built by the same compiler that CPython is. If CPython used an old clang without support for that flag and the extension module compiled by that CPython via pip and setup.py, etc. uses a more recent version of clang - it wouldn't specify that flag and the extension module code could be broken.

I suppose this issue of conditional compiler flags is nothing new. It should not block us from going forward with a workaround like your PRs for now.

gpshead · 2019-04-12T22:50:25Z

I believe -fno-max-type-align is also an option.

vstinner · 2019-04-12T22:51:10Z

New changeset a304b13 by Victor Stinner in branch 'master':
bpo-36618: Don't add -fmax-type-align flag to old clang (GH-12811)
a304b13

vstinner · 2019-04-12T22:55:11Z

It should not block us from going forward with a workaround like your PRs for now.

I pushed a fix quickly to unblock my PR 12796, but also because I was very scared by what I saw :-D

I see my change as a "quick fix", but we really have to sit down to think about the "correct fix". Especially since we will have to do something for Python 2.7 and 3.7, and adding -fmax-type-align=8 to exported CFLAGS can cause *new* issues, as you explained.

That's why I mentioned bpo-27987 and other issues, to try to see what has already been said, and try to find to identify and fix the root issue, rather than working around the issue with compiler flags.

fweimer · 2019-04-15T11:02:44Z

The issue is related to the definition of PyCArgObject:

typedef struct tagPyCArgObject PyCArgObject;

struct tagPyCArgObject {
    PyObject_HEAD
    ffi_type *pffi_type;
    char tag;
    union {
        char c;
        char b;
        short h;
        int i;
        long l;
        long long q;
        long double D;
        double d;
        float f;
        void *p;
    } value;
    PyObject *obj;
    Py_ssize_t size; /* for the 'V' tag */
};

This object must be allocated with suitable alignment (which is 16 on many platforms), and the default Python allocator apparently provides 8-byte alignment only on 64-bit platforms. In short, using PyObject_New with PyCArgObject results in undefined behavior.

This issue potentially affects all compilers, not just Clang.

vstinner · 2019-04-15T14:45:20Z

C++ has a __alignof__ function/macro/operator (not sure what is its kind) to get the alignment of a type.

C11 has <stdalign.h> header which provides an alignof() function.

GCC has __alignof__().

I also found "_Alignof()" name.

... no sure which one is the most portable ...

vstinner · 2019-04-15T14:47:01Z

I also found this macro:

#define ALIGNOF(type) offsetof (struct { char c; type member; }, member)

vstinner · 2019-04-15T14:47:56Z

More info on alignof():
http://www.wambold.com/Martin/writings/alignof.html

serge-sans-paille · 2019-04-16T09:19:35Z

@vstinner: once you have a portable version of alignof, you can deciding to *not* use the pool allocator if the required alignment is greater than 8B, or you could modify the pool allocator to take alignment information as an extra parameter?

vstinner · 2019-05-14T17:29:56Z

New changeset d97adfb by Victor Stinner in branch 'master':
bpo-36618: Don't add -fmax-type-align=8 flag for clang (GH-13320)
d97adfb

vstinner · 2019-05-14T17:31:21Z

Python 3.8 now respects the x86-64 ABI: https://bugs.python.org/issue27987

I reverted my workaround.

vstinner added 3.8 (EOL) end of life build The build process and cross-build labels Apr 12, 2019

vstinner closed this as completed May 14, 2019

ezio-melotti transferred this issue from another repository Apr 10, 2022

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

clang expects memory aligned on 16 bytes, but pymalloc aligns to 8 bytes #80799

clang expects memory aligned on 16 bytes, but pymalloc aligns to 8 bytes #80799

vstinner commented Apr 12, 2019

vstinner commented Apr 12, 2019

vstinner commented Apr 12, 2019

vstinner commented Apr 12, 2019

vstinner commented Apr 12, 2019

vstinner commented Apr 12, 2019

vstinner commented Apr 12, 2019

gpshead commented Apr 12, 2019

gpshead commented Apr 12, 2019

vstinner commented Apr 12, 2019

vstinner commented Apr 12, 2019

fweimer mannequin commented Apr 15, 2019

vstinner commented Apr 15, 2019

vstinner commented Apr 15, 2019

vstinner commented Apr 15, 2019

serge-sans-paille mannequin commented Apr 16, 2019

vstinner commented May 14, 2019

vstinner commented May 14, 2019

clang expects memory aligned on 16 bytes, but pymalloc aligns to 8 bytes #80799

clang expects memory aligned on 16 bytes, but pymalloc aligns to 8 bytes #80799

Comments

vstinner commented Apr 12, 2019

vstinner commented Apr 12, 2019

vstinner commented Apr 12, 2019

vstinner commented Apr 12, 2019

vstinner commented Apr 12, 2019

vstinner commented Apr 12, 2019

vstinner commented Apr 12, 2019

gpshead commented Apr 12, 2019

gpshead commented Apr 12, 2019

vstinner commented Apr 12, 2019

vstinner commented Apr 12, 2019

fweimer mannequin commented Apr 15, 2019

vstinner commented Apr 15, 2019

vstinner commented Apr 15, 2019

vstinner commented Apr 15, 2019

serge-sans-paille mannequin commented Apr 16, 2019

vstinner commented May 14, 2019

vstinner commented May 14, 2019