Oooh. A memory leak. Interesting. Unfortunately, the failure isn't necessarily where the program stops.
Abort is usually triggered by the c library when you free something that isn't supposed to be free'd. This is usually a result of corrupted memory from "something" overwriting the pointer you want to free.
Generally, what happens is something like this:
Code:
- in part of the code, you allocate an array of data (in this case, HISTORY_SIZE char* pointers).
- somewhere else in the code, memory is altered somewhere "earlier" in the memory. This will not look like it has anything to do with the history-structure.
- the overflow alters some bits outside the designated space through the use of an unsafe copy-function like strcpy or bad counting or other bug.
- now, when the free() function need to do stuff, it encounters a pointer never allocated in the first place.
- free() raises an abort signal, because this is not something it knows how to handle.
So, what to do about it? Well, there are a couple of options.
Some people use the tool valgrind to do this.
valgrind.org/docs/manual/quick-start.html
It is a very powerful tool, but can be a little daunting.
Others will note that we have built in a memory debugger, in the zmalloc.c/h files:
github.com/tbamud/tbamud/blob/master/src/zmalloc.c#L12
<-- here's how to install it.
Regardless of which solution you use, I suggest running in mini-mud mode first. Both use an extravagant amount of memory. And both require you to run your mud, then shut it down to see the output.
