Hi, On Thu, Jun 2, 2011 at 3:15 PM, John Stebbins <[email protected]> wrote: > On 04/26/2011 09:28 AM, Vitor Sessak wrote: >> >> Module: libav >> Branch: master >> Commit: 13dfce3d44f99a2d7df71aba8ae003d58db726f7 >> >> Author: Vitor Sessak<[email protected]> >> Committer: Reinhard Tartler<[email protected]> >> Date: Sat Apr 23 19:24:31 2011 +0200 >> >> Increase alignment of av_malloc() as needed by AVX ASM. >> >> Signed-off-by: Reinhard Tartler<[email protected]> >> >> --- >> >> libavutil/mem.c | 16 +++++++--------- >> 1 files changed, 7 insertions(+), 9 deletions(-) >> >> diff --git a/libavutil/mem.c b/libavutil/mem.c >> index 2aef9b0..27bb30b 100644 >> --- a/libavutil/mem.c >> +++ b/libavutil/mem.c >> @@ -69,21 +69,21 @@ void *av_malloc(size_t size) >> #endif >> >> /* let's disallow possible ambiguous cases */ >> - if(size> (INT_MAX-16) ) >> + if(size> (INT_MAX-32) ) >> return NULL; >> >> #if CONFIG_MEMALIGN_HACK >> - ptr = malloc(size+16); >> + ptr = malloc(size+32); >> if(!ptr) >> return ptr; >> - diff= ((-(long)ptr - 1)&15) + 1; >> + diff= ((-(long)ptr - 1)&31) + 1; >> ptr = (char*)ptr + diff; >> ((char*)ptr)[-1]= diff; >> #elif HAVE_POSIX_MEMALIGN >> - if (posix_memalign(&ptr,16,size)) >> + if (posix_memalign(&ptr,32,size)) >> ptr = NULL; >> #elif HAVE_MEMALIGN >> - ptr = memalign(16,size); >> + ptr = memalign(32,size); >> /* Why 64? >> Indeed, we should align it: >> on 4 for 386 >> @@ -93,10 +93,8 @@ void *av_malloc(size_t size) >> Because L1 and L2 caches are aligned on those values. >> But I don't want to code such logic here! >> */ >> - /* Why 16? >> - Because some CPUs need alignment, for example SSE2 on P4,& most >> RISC CPUs >> - it will just trigger an exception and the unaligned load will be >> done in the >> - exception handler or it will just segfault (SSE2 on P4). >> + /* Why 32? >> + For AVX ASM. SSE / NEON needs only 16. >> Why not larger? Because I did not see a difference in benchmarks >> ... >> */ >> /* benchmarks with P3 >> >> > This commit breaks OSX on SDK 10.6 which has a broken posix_memalign > implementation. /Ronald Bultje /has mentioned this OSX bug in other threads > on this list. When alignment >=32 && size == 0, posix_memalign returns an > invalid pointer along with a success code. So subsequent free corrupts the > heap. Something like the attached patch fixes the issue. >
I've tried to fix all occurrences of this in the code. I don't want to put a workaround in av_malloc(), I think it's better not to call the function when size==0 anyway. (Not to mention OSX is broken and Apple isn't responding to my bug report.) Ronald _______________________________________________ libav-devel mailing list [email protected] https://lists.libav.org/mailman/listinfo/libav-devel
