[Bug malloc/27227] New: Memory corruption for altivec unaligned load / store

["kungfujesus06 at gmail dot com" <sourceware-bugzilla@sourceware.org>]

https://sourceware.org/bugzilla/show_bug.cgi?id=27227

            Bug ID: 27227
           Summary: Memory corruption for altivec unaligned load / store
           Product: glibc
           Version: 2.32
            Status: UNCONFIRMED
          Severity: normal
          Priority: P2
         Component: malloc
          Assignee: unassigned at sourceware dot org
          Reporter: kungfujesus06 at gmail dot com
  Target Milestone: ---

I'm not 100% sure this is a bug in assumptions made by the allocator or this is
a data hazard I've always had.  I'm seeing memory corruption in the following
scenario (I might try to produce a minimal case but if somebody can tell me
what I'm doing is in fact dumb before then, then I won't have to do so):

__vector loadu_f32(float *v)
{
    __vector unsigned char permute = vec_lvsl(0, (unsigned char*)v);
    __vector unsigned char lo = vec_ld(0, v);
    __vector unsigned char hi = vec_ld(16, v);
    return vec_perm(lo, hi, permute);
}

float *ptr3d = (float*)_mm_malloc(3 * sizeof(float) * someSizeNotModulusOf4,
16);
size_t numIterations = someSizeNotModulusOf4 / 4;

/* assume ptr3d was populated at some point, in some scalar loop */

for (size_t i = 0; i < numIterations; ++i) {
    __vector x = vec_ld(i*4, ptr3d);
    __vector y = loadu_f32(&ptr3d[someSizeNotModulusOf4+4*i]);
    __vector z = loadu_f32(&ptr3d[2*someSizeNotModulusOf4+4*i]);
}

/* remainder peeling scalar loop goes here */


This structure of a loop seems to cause memory corruption, with assertions
being thrown in malloc.  As far as I can tell, this is _the_ convention to use
for unaligned loads for altivec enabled powerpc machines that don't have VSX:
http://mirror.informatimago.com/next/developer.apple.com/hardware/ve/alignment.html

According to this, so long as some bytes of the second half being loaded (hi)
are on the heap bounds, it should be safe based on heap alignment.  Now, this
is Linux with glibc, not Mac OS X, but I swear this code worked cleanly before
and doesn't seem to be now.  Even weirder, if for malloc I drop in something
that does oversized allocations by 16 bytes, it won't crash, but I see some
evidence of corruption sometime after FFTW uses some altivec enabled kernels. 
When compiling with asan, it catches the out of heap bounds load and complains
loudly without the oversized allocations.  I could see this being a false
positive, for the second half of the load, but it doesn't make sense why the
unaligned loads and stores are then causing corruption later when oversized.

Strangely, LD_PRELOAD'ing Intel's TBB pool allocator proxy for malloc and free
make these symptoms disappear entirely (it's probably oversizing _all_ calls to
malloc/posix_memalign).  

Did some behavior change with regard to this or was this way of doing
misaligned loads always hazardous and I managed to get lucky?

-- 
You are receiving this mail because:
You are on the CC list for the bug.