Re: CF: debugging crossfire malloc()'s

["Mark Wedel" <mwedel@pyramid.com>]

On Oct 11,  5:13pm, Frits Daalmans wrote:
> Subject: CF: debugging crossfire malloc()'s
> Hello,
>
> 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
>

 A few quick notes:

 If you use something like the dmalloc library, you already have bounds
checking mechanisms in place (to check for structure overruns.)  dmalloc is a
free/shareware product, so can be installed on any system.

 The use of putting a starting tag on all the alloc'd objects would require a
lot of updates to make sure they are set correctly (if you miss a few areas,
then that code becomes a bit less useful...)

 But I have seen very few cases where problems are caused my bad memory
accesses or other malloc corruption.  Most is caused be looking at invalid
pointers and so forth.




-- 
 --Mark