Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
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.