Date: Wed, 17 Apr 2013 03:25:32 +0200 From: magnum <john.magnum@...hmail.com> To: john-dev@...ts.openwall.com Subject: Re: Segfaults probably caused by DEBUG code in memory.c (was: Segfault for linux-x86-native with -DDEBUG added) On 16 Apr, 2013, at 20:06 , magnum <john.magnum@...hmail.com> wrote: > I also fixed the bug below. This one actually exist in core too, although I'm not sure any core format uses mem_alloc_tiny() for SSE2 buffers. > > #if ARCH_ALLOWS_UNALIGNED > - if (mem_saving_level > 2) > + if (mem_saving_level > 2 && align != MEM_ALIGN_SIMD) > align = MEM_ALIGN_NONE; > #endif Since we sometimes align to something larger, like MEM_ALIGN_CACHE or MEM_ALIGN_PAGE, the above is not enough: I could still segfault an sse2 build of unstable using --save-memory=3. I'll need to do this (ignoring the slight "impact" on VAX and x86-any): #if ARCH_ALLOWS_UNALIGNED if (mem_saving_level > 2 && align < MEM_ALIGN_SIMD) align = MEM_ALIGN_NONE; #endif MEM_ALIGN_SIMD is a Jumbo-only definition, it falls back to 16 on non-MMX/SSE. I haven't managed to segfault an SSE2-build of core John using --save-memory=3 but after briefly looking at the code I suspect it could happen. On another note we should mute the self-test warnings (in bleeding) for unaligned salts/binaries when this is used. This too also applies to core iirc. magnum
Powered by blists - more mailing lists
Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.