alloca and allocaArray do not respect alignment

When allocating memory with alloca or allocaArray the alignment of the Storable is not respected, alignment seems to be on 8 byte boundary. malloc and mallocArray seem to have the same problem. And because of this functions like withArray etc also break the alignment restriction of the array element.

Run this and look at the pointer.

import Foreign.Ptr
import Foreign.Storable
import Foreign.Marshal.Array
import Foreign.Marshal

data Foo = Foo

instance Storable Foo where
    sizeOf _ = 8
    alignment _ = 256

main =
    allocaArray 5 $ \ p -> do
    let _ = p :: Ptr Foo
    print p
    q <- mallocArray 5
    let _ = q :: Ptr Foo
    print q

Trac metadata

Trac field	Value
Version	6.10.1
Type	Bug
TypeOfFailure	OtherFailure
Priority	normal
Resolution	Unresolved
Component	Compiler (FFI)
Test case
Differential revisions
BlockedBy
Related
Blocking
CC	lennart@augustsson.net
Operating system
Architecture	x86

mentioned in issue #1605 (closed)

changed weight to 5

added FFI Tbug Trac import labels

Attached file alignment.patch (download).

Patch to use alignment.

I've added a patch to use the alignment when allocating.

Thanks for the patch. As it stands, this will waste memory when the required alignment is <= 8 bytes, since allocaBytes and mallocBytes both always return 8-byte aligned memory. Could you modify the patch to take that into account?

Trying to fix my patch to not waste memory I realized that the patch is broken. It takes a pointer from some internal malloc and adjusts it for alignment. This will not work when that pointer is later given to free.

I'm not sure how to fix this. It seems we need to have the low level allocator return a pointer that is properly aligned, otherwise giving the block back to the low level free will never work.

In short, I don't know how to fix this.

Note that this is a real problem. Using SSE instructions on the x86 requires the vectors to be properly aligned, otherwise you get a fault. So I can't use any of the allocators for Storable in Foreign (nor Data.Array.Storable) when allocating vectors.

A hack would be to have the allocator return everything 16 byte aligned, but that really is a hack. The longer term solution must take alignment into account.

-- Lennart

I'm working on a new patch that I think will work, except it relies on posix_memalign() which seems to be a rare beast.

Yes, good point. The allocaBytes version is fine, btw (except that it should avoid wasting memory when alignement <= 8). posix_memalign() is the only way I know to allocate aligned memory from the OS.

Attached file align.patch (download).

New alignment patch.

mentioned in issue #2983 (closed)

changed milestone to %6.10.2

changed weight to 7

Trac metadata

Trac field	Value
Priority	normal → high

I'm a little nervous about rushing this in, particularly as it changes (adds to) some APIs, and I'm not sure exactly what the behaviour should be.

You say

mallocAlignment :: Int
mallocAlignment = 16
allocaAlignment :: Int
allocaAlignment = 8

but my manpage says

GNU libc malloc() always returns 8-byte aligned  memory  addresses

Where did 16 come from? It also seems strange to me that allocaAlignment should be different to mallocAlignment.

According to my OS X manpages, OS X doesn't have posix_memalign or memalign, although it does have valloc ("The allocated memory is aligned on a page boundary."). However, for all the allocation functions on OS X, "The allocated memory is aligned such that it can be used for any data type, including AltiVec- and SSE-related types.". So if we're told the alignment is 32, and we get memory 16-byte aligned, should we fail? It's not clear to me.

The mallocAlignment is the alignment returned by C malloc(), the allocaAlignment is the alignment for ghc's heap based allocation. I should have spelled that out. Those two things should not be numbers, of course, but determined by the configure script.

yes, OS X malloc() works fine, but ghc's internal allocation fails since it allocates on 8 byte boundary.

I don't want to rush this in either. But the bug makes large parts of the FFI library unusable with LLVM, so I'd like some fix. How about a band aid that changes ghc's internal alloca to 16 byte boundary? That will make things work, and we have a chance to test my patch further.

-- Lennart

assigned to @simonmar

I'll do as Lennart suggests and bump the default alignment to 16 bytes.

mentioned in commit b220844f

mentioned in commit 19f85473