@Lithium said in Really wierd happening...:
@Thenomain I just tore it down and am rebuilding it from scratch. I didn't have a lot of code in there to really be a problem to redo it all. Will take a very short amount of time.
Just don't know why it happened in the first place... Kind of frustrating. I'm just glad I don't have to much stuff on there right now. I kept flip flopping on systems so there wasn't a ton of code on the game at the moment.
EDIT: Yes, I do do backups.
I realize I'm doing a bit of a necro, but figured I would toss in a reason for why this happened so that if you or others run across this, you can realize what is going on.
MUX, TinyMUSH3, Rhost, and in some ways Penn, based on how they do data storage have a structure based on the data type that is based on a bitwise mask.
Penn because of how they write their data, funny enough, is not as vulnerable to this as they use a method similar to a wacky XML format, however, TinyMUSH3, MUX2, and Rhost can be vulnerable to this.
This goes way back to MUX 1.x, TinyMUSH, TinyMUD and all the other old codebases that used to use GDBM database. GDBM used a 4096 buffer for the cache, including attribute reads and writes. The A_LIST (internal attribute keeper) for attributes would store the 4 byte integer value of the attribute followed by a seperator. This would mean that on any database using GDBM where you have a 4 byte int (and not, say, Tru64 which uses 8 bytes), you were limited to 4096/5 + 1 (for the null) attributes per object before the 4096 internal cache buffer had to be split and chunked into a new cache buffer. This was seen, by gdbm, as not an issue. The reason is because GDBM was smart enough to recognize it needed to cache up a new buffer. MUSH/MUX was smart enough to realize it's not a problem, because they knew that GDBM did so.
But. There is a problem. GDBM didn't order how or when the cache tables were written. It would put a pointer marker of where and how it was written, but it would not necessarilly write them --in order--. This would mean you now have data written in a structure out of order, which, you guessed it, would corrupt your table. This means that you could, potentially, have values overwrite your structure data turning a data type of, oh say EXIT, into a ROOM, a player, or so forth. Have attributes randomly show up on other things. Attribute contents (greater than 4096 bytes) randomly show up on other attributes or disappear alltogether. This was a common occurance seen in older TinyMUSH and MUX 1.6 systems.
Then MUX 2.0 came out and Brazil made a completely new backend db engine. The corruption suddenly 'went away'. Funny that.
Rhost realized the limitations of GDBM and we hard-capped attribs to get around it until we went to QDBM which no longer had this issue.
TinyMUSH 3.3+ now uses QDBM as well.
Penn went to a new db format from 1.8.0+.
So, you ask yourself, without GDBM, why do I get something that looks like this exact same db corruption?
Well, glad you asked!
There's still ways that every codebase can still get corruption. The most common are five ways:
- You suffered a backout or brownout while the database was being written so you have partial or corrupt data in your database.
- You suffered a quota exceed limit or the mount point on the disk is filled so it had no room to write the data to disk.
- You opened the database with another tool at the same time the mush was attempting to write the data to it which would cause some... issues... depending on the database being used (QDBM is notoriously nasty when you open it in write mode when it's currently open by the mush).
- The code you're running is buggy and has an overflow (stack or buffer) that is blowing away values in memory and/or disk before it's being written and overwriting values.
- You have a BIOS on your computer that's not 100% compatible with the disk you are using, or you're using a filesystem that doesn't fully support disk write-ahead and your disk is corrupting saves because of write-ahead, or your physical disk is failing.
#4 is easy enough to identify because it likely will keep occurring when certain commands or functions are used.
#1 is easy enough as you can check uptime to see if the server you're on has bounced.
#2 and #5 are a bit harder to identify, especially if you do not have system administrator access on the system in question. If you do, refer to the /var/log/messages (or /var/adm/messages depending on the UNIX flavor) and see if you can find any I/O errors in the logs. df to see how much free disk space you have. usa 'quota' to make sure you don't run out of account quotas. When you run active backups and you have quotas enabled, it's quite easy to run out of disk without realizing it since backups can chew up disk space quicker than you expect.
All this boils down to that the only way actively to change a data type in a mu* database is with db corruption. As soon as you ever see it in your database, the reliability of your database is now in question. At this point you should backup everything you want and then load in a backup database and load in everything you could save from the db in question.
MUX2, Penn, and Rhost are very resiliant mush engines, but nothing can save against acts of God other than backups backups backups.
Good luck, and hope your mush is doing good.
And, again, I apologize for the necro.