Re: [RELEASE] [CODE] [LONG] Guilds Code Info.

From: James Turner (turnerjh@XTN.NET)
Date: 04/29/98


Daniel Koepke <dkoepke@CALIFORNIA.COM> writes:

> This could be a bad thing to do, given that after a segmentation
> fault, you cannot assume your data is valid (in fact, invalid data is
> probably what caused the crash).  Saving that data and reloading the
> MUD with the same corrupted data (hence causing the game to seg.
> fault again and attempt to reload with the same corrupted data) would
> turn your site into a virtual Aceldama.  (I'm assuming that copyover
> saves the players, then writes out some vital information to a
> seperate file.)

Something I mentioned in a different thread on a similar idea is
always using accessor functions for setting data in the char_data
structures.  Allocate everything that belongs to a char_data (ie
strings, substructures, etc) using a different allocator -- one that
uses mprotect to guard the data.  Then, when a crash hits, you know
the data is safe -- memory overwrites aren't possible since the first
time something tries to write to any character data, a segfault is
generated.  Player data would be protected, but at the cost of a fair
amount of overhead (though mprotect should be a very fast call since
it more or less maps directly to hardware functions).

The only danger is when code generates invalid data and it hides in
the structures (that are assumed valid).  But if this is the case, it
is quite possible a player would have saved on their own anyway,
thereby committing the bad data to the pfile.  Such corruptions would
be the product of bad code and somewhat traceable (more traceable than
random memory corruptions).

--
James Turner               turnerjh@xtn.net
                           http://www.vuse.vanderbilt.edu/~turnerjh/


     +------------------------------------------------------------+
     | Ensure that you have read the CircleMUD Mailing List FAQ:  |
     | http://democracy.queensu.ca/~fletcher/Circle/list-faq.html |
     +------------------------------------------------------------+



This archive was generated by hypermail 2b30 : 12/15/00 PST