Hitting segmentation fault issue when trying to replicate malloc - c

Question

Background:
I'm working through a project whose goal is to build a memory management system that replicates malloc() and free(). The program begins by requesting a specified amount of memory from the operating system with mmap and then uses a linked list to keep track of which sections of memory are in use or free. See below for a general idea of what I'm doing.
Output after allocating one chunk of memory
Question
Why do I hit a segmentation fault when trying to create a new list node to represent free memory? This segmentation fault occurs only when trying to request more than two chunks of memory - the first works as expected.
Details
The segmentation fault occurs when trying to assign values to the attributes of the node just created (new in the code below) to represent the remaining free memory space. This assignment works the first time I split memory into used v. free segments, but the second time I try to split the free memory into used v. free segments, my program encounters a segmentation fault - I am assuming this occurs because the attributes of the new node_t struct are undefined (compiler doesn't know where they live in memory). What I don't know is why this is occurring, and why it doesn't occur the first time I use this code.
NOTE: The answer shouldn't be to use malloc when initializing the *new node because the point of the project is to do this without using malloc. Malloc wouldn't allocate from the memory I'm managing - instead, it'd allocate from the heap my program is actually maintaining (but not using) on the side.
Struct definitions:
typedef enum {false, true} bool;
typedef struct _node_t {
int size;
struct _node_t *next;
struct _node_t *prev;
bool used;
} node_t;
Problem code. ret is the memory allocation I'm going to return to the caller and new is the remainder of the free memory block I just allocated part of.
// Code above this steps through the list elements to find the first free
// element that is large enough. I've debugged enough to know that's not the
// source of the problem.
node_t *new = ret + sizeof(node_t) + size; // Pointer to new free slot
assert(new != NULL);
new->prev = ret;
new->next = ret->next;
new->size = ret->size - sizeof(node_t) - size;
new->used = false;
ret->used = true;
ret->next = new;
ret->size = size;
return (ret + sizeof(node_t));
Calling code:
int main(int argc, char* argv[]) {
int success = Mem_Init(5000, P_FIRSTFIT);
if (success == -1)
return -1;
int *slot1 = Mem_Alloc(sizeof(int));
// This is where segmentation fault occurs
int *slot2 = Mem_Alloc(sizeof(int));
Link to code you can compile and run.

Answer 1

Although you don't include a definition of ret and Dropbox is totally useless for viewing code on a smartphone, I think we can deduce the declaration
node_t* ret;
Otherwise ret->next won't compile.
In that case, ret + sizeof(node_t) does not make sense because of the nature of pointer arithmetic in C. Remember that p + k is exactly the same as &p[k]. In other words, p + 1 is the address of the next element of size sizeof*p. So ret + sizeof(node_t) is the address of the 16th or 32nd element after ret, depending on the sizeof (node_t).
What you probably wanted was ret + 1, whose simplicity illustrates the rationale behind C pointer arithmetic.

Answer 2

The answer: It's all in pointer math. The issue was this statement:
node_t *new = ret + sizeof(node_t) + size; // Pointer to new free slot
Any integer in the right hand side of this equation doesn't increment the memory address by one byte... it increments it to the next spot where a node_t struct would begin. So in the code above, the address of new is set (32 + size) * 32 bytes further along in memory (assuming sizeof(node_t) is 32, which is true on a 64 bit system). Do that enough and you run well outside of the 500 bytes of memory you actually requested from the OS.
The code that works is:
node_t *new = ret + 1 + (size / sizeof(node_t)) + 1;
This code ends up over-allocating memory a bit if size isn't exactly equal to sizeof(node_t), but that's a problem with a more complicated solution. For illustration, consider this example:
ret = address 1000
sizeof(node_t) = 32 (in a 64 bit system)
size = 50
The end of the header for ret is address 1032 in this example. The program then allocates 2x32 bytes to handle the 50 byte request (math is (50 / 32) + 1 = 2, or two node_t structs). So the memory address of new is actually 1096.
To make this work overall, I'll also have to update the size calculation to reflect the actual allocation instead of the requested allocation. This will be necessary to make a safeguard against running outside of the bounds of memory requested from the OS work properly.