[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <8a07fb7709ed725aab0886a3b1e9ee99@smtp.hushmail.com>
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.
