16 Feb, 2014, Davenge wrote in the 1st comment:
Votes: 0
How reliable is it to use signal() to catch the mud crashing and save everything just before it crashes? I mean, 99% of the time SIGSEV is why I'm crashing so if I just save my world then, is that a reliable way to hold a muds "state" through crash without using a live database?
16 Feb, 2014, quixadhal wrote in the 2nd comment:
Votes: 0
It's generally a really BAD idea to try to do this.

Your MUD is crashing for a reason, and you don't know what that reason is. You only know the symptom that manifests as a segmentation fault (attempt to access memory your process doesn't own). Because you don't know that your data in memory has not been corrupted, catching that signal and trying to save state is a great way to corrupt your game files or database.

Try fixing the problem, instead of sweeping it under the carpet and hoping nobody notices the smell.
16 Feb, 2014, Tyche wrote in the 3rd comment:
Votes: 0
It's completely unreliable. You need to fix the errors.
16 Feb, 2014, Davenge wrote in the 4th comment:
Votes: 0
Uh….OBVIOUSLY I'M GOING TO FIX THE PROBLEM!!!

By state, I was referring to saving valid entities. That aren't trying to access NULL pointers. LOL, wtf kind of hack do you think I am?

Let me rephrase, instead of saving a pFile every time they move or an object every time its dropped so it remembers what room its in, would it be reliable to catch a SIGSEV and save then assuming there were checks in place to make sure the stuff saving wasn't corrupt?

Holy crap… I'm a little insulted, though, maybe my question was poorly worded?

Edit: Sure, some things need to be saved as soon as they happen, especially objects to prevent duping but that was just an example off the top of my head. Didn't want you to think I hadn't considered that either…………
16 Feb, 2014, Tyche wrote in the 5th comment:
Votes: 0
Mine was just a matter of fact reply.
Yes, you can check for a null pointer before de-referencing, and that's a good way to prevent SIGSEGV.
However, merely checking for null pointers isn't going to validate data.
How do you check for a wild pointer in the data?
How do you save data, when IO calls are known to be unsafe to call after SIGSEGV?
17 Feb, 2014, Davenge wrote in the 6th comment:
Votes: 0
These are valid points. If it is unsafe, its unsafe. That's what I wanted to know.

This wasn't some goal to never have to fix what was crashing the mud… just curious if it was a safe way to "gracefully shut down"(as I've seen it called) and maybe cut down on the frequency of I/O calls in my code.
17 Feb, 2014, quixadhal wrote in the 7th comment:
Votes: 0
Here's a not uncommon scenario.

You have pointer errors in your code, somewhere. Maybe it's a buffer overflow, or maybe it's an invalid pointer. In either case, when you write data through that pointer, you are writing into memory OTHER than where you intended to write. If that happens to point outside a valid segment, you will get a segmentation fault. If it points to a VALID address within your data segment, you will cheerfully overwrite values in OTHER variables of your program, and you will NEVER KNOW that it happened.

So, if you trapped SIGSEGV, and then managed to write out your data… how do you know the data you just saved hasn't been corrupted by a different pointer error? Unless you've implemented some kind of checksum for your data structures, which gets updated whenever they change?

You can, of course, claim the same thing if you don't get any signal errors… but where there's smoke, there's often fire.
17 Feb, 2014, Davenge wrote in the 8th comment:
Votes: 0
Indeed and of course that makes sense, I've dealt with that sort of stuff before. And that was my thinking, it could happen one way or the other but you are right, when there is smoke there is often fire.
17 Feb, 2014, alteraeon wrote in the 9th comment:
Votes: 0
The vast majority of your segmentation faults are going to be NULL pointer dereferences, so in most cases it is actually ok to do some shutdown code in your signal handler. Alter Aeon does a fair amount of clean shutdown work when it crashes, including sending a crash message out the comm stack and dumping various debug to figure out what happened. However, one of the things we explicitly don't do is save data files. There's a lot of stuff that would be fairly safe to save, but imho it's just not worth the risk or hassle.

-dentin

Alter Aeon MUD
http://www.alteraeon.com
17 Feb, 2014, plamzi wrote in the 10th comment:
Votes: 0
Practically speaking, you *could* try to save anything that you know would be completely lost if you didn't. Examples in our case include equipment on dead bodies of players or their minions.

Even if the data is not 100% sound, it is much easier (and less error-prone) to sanity-check equipment in the database than to have to restore people's equipment from backup.

Of course, the only real solution is to debug. But if you are on a fast development track, and you know that there will be times of instability as a tradeoff to rolling out major features, I think some code to make your crashes less work to recover from is totally fine.

Granted, I'm like, a non-purist.
17 Feb, 2014, Hades_Kane wrote in the 11th comment:
Votes: 0
In the case of players losing equipment… I implemented and modified the "locker" code available on this site as a snippet to help with that. In the few instances that we've had a crash where someone had a corpse full of equipment on the ground, it's been a big help.

So yeah, there are other ways around preserving certain things than saving just on the case of a crash.
18 Feb, 2014, Tyche wrote in the 12th comment:
Votes: 0
Davenge said:
These are valid points. If it is unsafe, its unsafe. That's what I wanted to know.

This wasn't some goal to never have to fix what was crashing the mud… just curious if it was a safe way to "gracefully shut down"(as I've seen it called) and maybe cut down on the frequency of I/O calls in my code.

Based on my experience, and hundreds of "help my mud is crashing posts" I've read, the vast majority of SIGSEGVs are caused by string buffer overruns.
So I would highly recommend using Safe String library.
Of course, if you're using the msvcrt, slibc, or blibc runtimes, then you already have access to an implementation.
Unfortunately, last I heard the maintainers of glibc aren't planning on implementing it, thus the alternative above.
18 Feb, 2014, quixadhal wrote in the 13th comment:
Votes: 0
Of course they won't… Heaven forbid they use code with a competing license in a GNU product. :stare:
18 Feb, 2014, Davenge wrote in the 14th comment:
Votes: 0
quixadhal said:
Of course they won't… Heaven forbid they use code with a competing license in a GNU product. :stare:

I'm surprised you can hear us from up there.
18 Feb, 2014, Tyche wrote in the 15th comment:
Votes: 0
quixadhal said:
Of course they won't… Heaven forbid they use code with a competing license in a GNU product. :stare:

I don't believe that's the issue. They don't appear to want to implement it.
After all slibc is under the same license and is designed to work along with glibc.
I'm quite certain the glibc group is competent enough to implement it on their own anyway.
18 Feb, 2014, Davenge wrote in the 16th comment:
Votes: 0
Davenge said:
quixadhal said:
Of course they won't… Heaven forbid they use code with a competing license in a GNU product. :stare:

I'm surprised you can hear us from up there.

I may have misunderstood, haha… weee…
18 Feb, 2014, Davenge wrote in the 17th comment:
Votes: 0
While we're on the topic of dangerous things… would it be considered dangerous to keep all your accounts and players loaded into memory even if they aren't logged in? More chance for them to get corrupted. Obviously, there would be a save when they player logged out but the actual structure would stay loaded into memory.
18 Feb, 2014, plamzi wrote in the 18th comment:
Votes: 0
Davenge said:
While we're on the topic of dangerous things… would it be considered dangerous to keep all your accounts and players loaded into memory even if they aren't logged in? More chance for them to get corrupted.


That would be true only if you are writing accounts regardless of whether they changed in memory or not. And why would you want to do that?
18 Feb, 2014, Davenge wrote in the 19th comment:
Votes: 0
Well, I was going to store object instances individually but that becomes a bit of a nuisance when I want to load an entire folder and the object's owner isn't logged in. I could store them within the mobile and coordinate files.

Meh, I've come up with a better way now.
18 Feb, 2014, alteraeon wrote in the 20th comment:
Votes: 0
Tyche said:
Davenge said:
These are valid points. If it is unsafe, its unsafe. That's what I wanted to know.

This wasn't some goal to never have to fix what was crashing the mud… just curious if it was a safe way to "gracefully shut down"(as I've seen it called) and maybe cut down on the frequency of I/O calls in my code.

Based on my experience, and hundreds of "help my mud is crashing posts" I've read, the vast majority of SIGSEGVs are caused by string buffer overruns.
So I would highly recommend using Safe String library.

Is that really that big of a problem? I literally cannot remember the last time I had a string buffer related crash, and I've never used a string safe library, just ordinary string handling functions and an overrun-proof buffer class. It's got to be on the order of at least five years or more.

Regarding the guy who saves files from the signal handler: beware. fopen/fwrite are not signal safe.

-dentin

Alter Aeon MUD
http://www.alteraeon.com
0.0/22