Date: Wed, 17 Apr 2013 01:26:45 +0200 From: magnum <john.magnum@...hmail.com> To: john-dev@...ts.openwall.com Subject: Re: Segfaults probably caused by DEBUG code in memory.c Blimey, you are right. I'll try this again, and test it well this time (in each branch) before committing :-) But I'll keep it in memory.c only, like you suggested first. No need to alter dynamic. magnum On 17 Apr, 2013, at 1:14 , "jfoug" <jfoug@....net> wrote: > Line 63 will NEVER be hit if MEM_ALLOC_SIZE is zero. There is a break in > that if condition, on line 61. I have not looked at the unstable version, > however. But the bleeding version worked fine for me (the #define > MEM_ALLOC_SIZE 0 in the .c file, right before the mem_alloc_tiny). > > Jim. > > From: magnum Sent: Tuesday, April 16, 2013 18:08 > To: john-dev@...ts.openwall.com > Subject: Re: [john-dev] Segfaults probably caused by DEBUG code in memory.c > > 58 > 59 if (size + mask > MEM_ALLOC_SIZE || > 60 bufree > MEM_ALLOC_MAX_WASTE) > 61 break; > 62 > 63 buffer = mem_alloc(MEM_ALLOC_SIZE); > 64 bufree = MEM_ALLOC_SIZE; > 65 } while (1); > 66 > 67 p = mem_alloc(size + mask); > 68 p += mask; > 69 p -= (size_t)p & mask; > 70 return p; > 71 } > > Now, if MEM_ALLOC_SIZE is 0 we will allocate 0 bytes in line 63, and never > get out of that loop. > > >
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.