DISPOSE Function in SWR

Posted by KipKerensky on Sun 09 Nov 2003 02:19 AM — 7 posts, 21,526 views.

#0
I've been trying to fix a bug for the past 4 days or so. On log in, either a new char or old sometimes, It will crash at getting a new password. Using gdb found was caused by DISPOSE in the free_char function. This occurs at both the DISPOSE(ch->pcdata) and DISPOSE(ch). In additiong to this, in clean_obj_queue, if try to eat/sac something that came in after quiting, DISPOSE(obj) does not work. If i comment out these lines the code works fine.

Using cygwin and have tried making sure all pointers are cleared or not. Appreciate any help.
USA #1
These errors can be extremely hard to track down. 99.9% of the time it is due to a mismatched allocation. You STRALLOC and then DISPOSE, resulting in a crash. STRALLOC must always be used with STRFREE, and str_dup must always be used with DISPOSE. Mixing the 2 is a recipe for disaster.

If your host has it installed, Valgrind is generally a great tool for locating things like this. Often it will catch it as it happens and you can then isolate it immediately. But either way it will pinpoint it at the moment your code crashes.
#2
Thanks for the help. You were right about the mismatched allocation errors. Took awhile to make sure everything was right.
Amended on Sun 09 Nov 2003 08:50 PM by KipKerensky
USA #3
This is one advantage of using C++ over C. Using its stronger typing, you can enforce that this kind of thing never happens. If your "hashed string" is a type of its own, then you can't call free on it, and you won't be able to call STR_ALLOC for a normal char *. Personally I find it extremely confusing to mix char* hashed and not hashed, and it's impossible to know which it is without tracing all the way back to the allocation.

So yes, this is one major advantage to using C++, for experienced programmers who care about this sort of thing.
USA #4
Which is one reason why I wanted to have my code compiled as C++ since it caught numerous mistakes I'd made in things just during compile. Fortunately I had the aid of Valgrind to spot the other disasters before I got to the point of using g++ to do my dirty work.
USA #5
What exactly is Valgrind? From what I've gathered by listening to you talk about it, it's some kind of gdb replacement program... is it that much better? What does it do that gdb doesn't do? Where do I get my hands on it? Is it free/open source? :)

Actually, it's amazing how many bugs a stock MUD in C will generate when you put it through g++. I've heard many argue that being strict about pointer casts and all that isn't necessary; well, perhaps, but so many bugs slip through due to poor error checking and strict compilation. I've ported my code base to C++ and it's sooo much nicer to work in. Not to mention that I don't have to waste time making my own data structures; since the STL implements so many (e.g. list, vector), you can worry about more important things (e.g. game, improvement).
USA #6
Valgrind is a memory debugger. Not intended to replace GDB, but instead meant to work with it. You can find it here: http://developer.kde.org/~sewardj/

Yes, it's free, open source, etc. I have it installed on both my servers and allow all my clients to make use of it as needed.

One thing to keep in mind is that it eats up alot of CPU and RAM, so if you're in a shared environment you'll need to keep that in mind. But it's a fabulous tool for tracking down memory related problems.