17 May, 2008, Rojan QDel wrote in the 1st comment:
Votes: 0
We have a SegVio handler in our MUD, but for some strange reason it only gets called on the first crash, after that it just crashes, not even starting the function… Has anyone had a problem like this or know how to fix it? Er sorry, the signal is SIGSEGV. SegVio is just the function that handles it.
17 May, 2008, Davion wrote in the 2nd comment:
Votes: 0
Well it's hard to say without seeing the code. A bug I had while making such a code was the copyover booted up slightly differently than the normal bootup and once copiedover it'd not initialize the signal handler. In the end though I just scrapped it, because a signal handler can cause some pretty serious data corruption, especially if you're force saving everything.
17 May, 2008, David Haley wrote in the 3rd comment:
Votes: 0
Well, if you really actually think that an emergency copyover is a good idea, then you're free to take your chances with it… This came up on the SmaugFUSS forum, see: this thread. I think it was resolved in the end.
17 May, 2008, Guest wrote in the 4th comment:
Votes: 0
Yes. I know how to fix it. You remove the code from your engine and let the thing crash when it needs to. It's probably not the fix you wanted though :P
18 May, 2008, Fizban wrote in the 5th comment:
Votes: 0
Quote
Yes. I know how to fix it. You remove the code from your engine and let the thing crash when it needs to. It's probably not the fix you wanted though :P


Unfortunately that is the best answer in my opinion, even if not the one he was looking for. An autorun script also barely interrupts players and has less chance of a 'true' interruption (read: corrupted player files). I've never seen a player get pissy because they had to retype their player name to log back on. On the other hand I have known players to quit on muds where their player file was corrupted and they lost immense amounts of work.
18 May, 2008, Rojan QDel wrote in the 6th comment:
Votes: 0
Thanks David, that's exactly my problem. And I'm using redhat too, must be a kernel or system libraries thing.
18 May, 2008, Rojan QDel wrote in the 7th comment:
Votes: 0
However, I'm not sure exactly how he resolved it…
18 May, 2008, Rojan QDel wrote in the 8th comment:
Votes: 0
Nevermind, got it.
18 May, 2008, Davion wrote in the 9th comment:
Votes: 0
Rojan QDel said:
Nevermind, got it.


Out of curiosity, what was the problem?
18 May, 2008, David Haley wrote in the 10th comment:
Votes: 0
For some reason, the signal handler was being reset after one signal handling, but if you want to keep the signal handler in place, you don't want that to happen. :wink: So you need to pick flags appropriately etc.
18 May, 2008, Rojan QDel wrote in the 11th comment:
Votes: 0
Basically, you use sigaction instead of signal, and don't set ANY flags. Since by default, the signal function sets some sort of reset flag. (on some distros).

Strange issue I discovered though..it solved the issue when I compiled with g++ 3, but when I compiled with g++ 4 it still only worked once, despite the sigaction. Obviously this is solvable by just using g++ 3, but I'm still curious why it happened.
18 May, 2008, David Haley wrote in the 12th comment:
Votes: 0
It has to do with what the C library is doing. It would seem that the gcc3 and gcc4 libraries aren't doing the same thing. :shrug:
0.0/12