From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id 78AF3398E438; Fri, 22 Jan 2021 17:45:36 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 78AF3398E438 From: "kungfujesus06 at gmail dot com" To: glibc-bugs@sourceware.org Subject: [Bug malloc/27227] New: Memory corruption for altivec unaligned load / store Date: Fri, 22 Jan 2021 17:45:36 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: new X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: glibc X-Bugzilla-Component: malloc X-Bugzilla-Version: 2.32 X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: kungfujesus06 at gmail dot com X-Bugzilla-Status: UNCONFIRMED X-Bugzilla-Resolution: X-Bugzilla-Priority: P2 X-Bugzilla-Assigned-To: unassigned at sourceware dot org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: bug_id short_desc product version bug_status bug_severity priority component assigned_to reporter target_milestone Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: http://sourceware.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: glibc-bugs@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Glibc-bugs mailing list List-Unsubscribe: , List-Archive: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Jan 2021 17:45:36 -0000 https://sourceware.org/bugzilla/show_bug.cgi?id=3D27227 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 thi= s is a data hazard I've always had. I'm seeing memory corruption in the followi= ng 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 =3D vec_lvsl(0, (unsigned char*)v); __vector unsigned char lo =3D vec_ld(0, v); __vector unsigned char hi =3D vec_ld(16, v); return vec_perm(lo, hi, permute); } float *ptr3d =3D (float*)_mm_malloc(3 * sizeof(float) * someSizeNotModulusO= f4, 16); size_t numIterations =3D someSizeNotModulusOf4 / 4; /* assume ptr3d was populated at some point, in some scalar loop */ for (size_t i =3D 0; i < numIterations; ++i) { __vector x =3D vec_ld(i*4, ptr3d); __vector y =3D loadu_f32(&ptr3d[someSizeNotModulusOf4+4*i]); __vector z =3D 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 VS= X: http://mirror.informatimago.com/next/developer.apple.com/hardware/ve/alignm= ent.html According to this, so long as some bytes of the second half being loaded (h= i) are on the heap bounds, it should be safe based on heap alignment. Now, th= is is Linux with glibc, not Mac OS X, but I swear this code worked cleanly bef= ore 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 kernel= s.=20 When compiling with asan, it catches the out of heap bounds load and compla= ins 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 f= ree make these symptoms disappear entirely (it's probably oversizing _all_ call= s to malloc/posix_memalign).=20=20 Did some behavior change with regard to this or was this way of doing misaligned loads always hazardous and I managed to get lucky? --=20 You are receiving this mail because: You are on the CC list for the bug.=