Really wierd happening...

Lithium

So I don't know exactly how this happened, but my builder staffer ended up carrying the player start room. Not just an object, but the /room/. I don't know how to relocate a whole room. Even if I link it to another room it'll still be in the inventory of that staffer instead of just... being.... Not sure how to fix this any idea's would be awesome.

EDIT: I am not sure if setting the player start room to a different db# would make the room destructible or not... but I suppose I can give that a shot.

EDIT 2: That allowed it to be destroyed, not sure /how/ it ended up being carried... never seen that happen before unless it for some reason teleported to it's owner's home from being unlinked or something... weird.

Cobalt

The first two things that come to mind:

One your build staff typed: "take #1234", but typoing the number of the player starting room.

Two your build staff was carrying something that got nuked, and then the player starting room was created afterward and took that old #dbref.

did 'drop #1234' not work to put the room back down rather than be in their inventory?

Lithium

@Cobaltasaurus It put the room down, but it was then an object inside the room where it was dropped. I eventually reset the starting room, nuked the old one, and redug it before anything else could take the db#, then linked it. I'm guessing what happened is the exit got nuked, so the room wasn't linked to the grid anymore, and it then ended up going 'home' which was the builder. That's just a guess though.

Thenomain

@Lithium

Unlinked rooms don't go "home" as there is no home for them to go to. I didn't think that there was a way to pick up a room, but there you go.

Lithium

@Thenomain

I didn't either, which is why I was so boggled by it. Somehow the room must have lost it's R (room) flag... I am at a loss, but, I got it fixed.

Sunny

Isn't one of the big warning signs of database corruption rooms becoming objects and getting moved around and such?

Lithium

@Sunny I have no idea, I've had zero crashes since I started the server months ago, though I have had code not work because, I suck as a coder. It might be I did something that removed the room flag, no idea... was just really really weird.

Thenomain

@Sunny said:

Isn't one of the big warning signs of database corruption rooms becoming objects and getting moved around and such?

I'm back. This hasn't happened for a long enough time that I forgot that this can happen. The Room flag is not really a flag. There is no way for this to change from within the game. None.

I started to wonder if maybe you accidentally set the StartingRoom in (game).conf to an object, which is possible. I hope so, because if you are somehow getting database corruption then there's no certainty that the underlying cause is resolved.

Keep backups.

Lithium

@Thenomain All my code is kept offsite so I can just port it in if I need to, and at this point any further backups I would do would have the same corruption if it is indeed corruption. I'll probably rebuild it from the ground up, just to be sure... but I don't even know what could have corrupted it. Like I said, no crashes or anything.

I'm torn between ripping it out and starting up a new version of mux 2.12 or not.

Sunny

@Thenomain said:

@Sunny said:

Isn't one of the big warning signs of database corruption rooms becoming objects and getting moved around and such?

I'm back. This hasn't happened for a long enough time that I forgot that this can happen. The Room flag is not really a flag. There is no way for this to change from within the game. None.

Yeah, it's been long enough that I'm excited I remembered this right. I've been involved with a couple of salvage projects over the years. ^^

Thenomain

You keep backups for more than having a backup; you keep them so you don't lose work. I have all my code off site as well but I would cut my wrists if I had to build a game from scratch. Do. Backups.

Lithium

@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.

Ashen-Shugar

@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.

Lithium

@Ashen-Shugar Thanks for the information. I am guessing that it was something to do with a power fluctuation or something because there wasn't a lot of code on it at the time, and what code I had in place, I have already put in place again with zero issues.

I suppose I could have opened the wrong thing in cpanel while the game was up as well, so it could have been that too.

Interesting stuff, even if it is as you said, a necro and a non-issue currently