[MUD-Dev] Re: TECH: reliablity (was: Distributed Muds)
derek at idirect.com
Mon Apr 30 12:21:16 New Zealand Standard Time 2001
>From Bruce, April 28, 2001 3:00 PM
> Derek Snider wrote:
>> Whatever programming utopia you exist in is far, far, far away from
>> the world of commercial game development... or any competitive
>> commercial development.
>> The larger and more complex a program gets, the more likely
>> something is to go wrong, and the harder it is to track it down.
>> The only way to have a bug-free program is to write it bug-free in
>> the first place.
>> Unfortunately this is nearly impossible with high-pressure
> This seems to be a rather self-defeating viewpoint. :(
No... I'm saying that "bugs happen", and that saying your code is 100%
bug-free is a very bold statement, usually guaranteeing a bug to pop
up quite soon after making such a statement.
I know how to write clean bug-free code. I just can't guarantee such
a thing when working on a project with several other people under a
>> I've used Purify and Insure, and many other memory debuggers, and
>> they usally choke on large complex programs that make heavy use of
> Insure does indeed fall over (and costs way too much). I've used it
> on Linux with big software and watched something take over 10 hours
> that usually takes about 5 minutes. However, I've run Purify and
> other memory debugging utilities on Solaris (and Linux where they
> were available) extensively and on large programs (like
> Mozilla). Even with a 700-800M process size, things were still
> manageable and worked acceptably.
I haven't used Purity personally (because I don't develop under
Solaris) but I've had programmers with access to it check the SMAUG
code, and it never found the errors that had to be found by hand.
> As a quick aside, in Smaug, you're leaking some memory allocated via
> the CREATE macro in mob_act_add() fairly regularly. I didn't see
> any unit tests in the 1.4a dist, so that was all I noticed in
> quickly running it under Purify.
Hmm... mob_act_add() allocates memory which gets freed by
aggr_update() at regular intervals. Could you be more specificy about
the memory leak there?
MUD-Dev mailing list
MUD-Dev at kanga.nu
More information about the MUD-Dev