[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <004601ce3ade$f1484880$d3d8d980$@net>
Date: Tue, 16 Apr 2013 15:14:04 -0500
From: "jfoug" <jfoug@....net>
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)
From: magnum Sent: Tuesday, April 16, 2013 14:32
>Not the same thing. In the normal non-debug code we obviously must do it,
because we are re-using one large >memory block for many smaller blocks.
That is one of mem_alloc_tiny's two reasons to exist.
I just tested this code, and it does the same thing as your original. It
simply forces mem_alloc_tiny to always allocate a block of memory for each
call into it (same as your replacement code did). mem_alloc_tiny is a
pretty ugly complex function. It's complexity reminds me of the complexity
of realloc, which is also a very tricky function.
#ifdef DEBUG
#undef MEM_ALLOC_SIZE
#define MEM_ALLOC_SIZE 0
#endif
void *mem_alloc_tiny(size_t size, size_t align)
{
//#ifdef DEBUG
// char *res;
//
// size_t mask = align-1;
// res = mem_alloc(size + mask);
// add_memory_link((void*)res);
// res += mask;
// res -= (size_t)res & mask;
// return res;
//#else
static char *buffer = NULL;
static size_t bufree = 0;
size_t mask;
...
p += mask;
p -= (size_t)p & mask;
return p;
//#endif
}
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.
