Crossfire Mailing List Archive
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

CF: debugging crossfire malloc()'s


I have an idea to help in debugging crossfire, but I am sure people have
thought about it or even implemented it yet, so I submit it here.
Please send flames to my E-mail address, not to the list :-)

Crossfire obviously allocates a lot of different types of data, map info,
objects, players etc. etc, and if something goes wrong you can see it
if it gives a core dump (doesn't always happen immediately), or if you 
run the server under a debugger (probably not recommended).

A trick I saw in the Linux kernel was, to do each allocation of a certain
interesting "type" of struct with an extra byte/word padding up front,
or as first element of the struct itself, 
and this word then contains a fixed "magic number" for what the data represents.

This way, if you allocate everything you really want to debug with its own
alloc/free routine, you can check:
- whether, if the pointer is not NULL, what magic number if any it contains
- if you want to free() something, whether it still has the good magic number

Simple example:

suppose we have a struct object{int magicnumber=0x0b1ec1, bla bla..};

it can be allocated with malloc

free() with routine free_object(struct object *o):
if (o->magicnumber == 0x0b1ec1)
free(o)  (well.. a bit more sophisticated than this, I'm sure :-)))

/* else */
print error message (try to free object but is not object)
check magicnumber against 0xb1a7e6, 0x3ab,  etc.
abort() optionally

(difficult to squeeze ASCII into hex... 
i,l -> 1 is OK, p -> b is OK??, but y -> 7 and r -> 6 and m -> 3 ??? 
I thought it would be readable to have magic numbers looking somewhat like
the words "object", "player" and "map", if you haven't guessed)

oh well you get the idea.

If this is already implemented, please tell me where?
If not, is it a good idea?


Frits Daalmans
OIO Conformational Analysis
Gorlaeus Laboratoria
Leiden, The Netherlands
Tel: [+31] (0)71-5274505