[MUD-Dev] Re: TECH: reliablity (was: Distributed Muds)

[Derek Snider]

>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
>> deadlines.
 
> 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
tight deadline.

>> I've used Purify and Insure, and many other memory debuggers, and
>> they usally choke on large complex programs that make heavy use of
>> memory.
 
> 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
https://www.kanga.nu/lists/listinfo/mud-dev