05 Jul, 2009, Banner wrote in the 1st comment:
Votes: 0
I returned home today to find my MUD hanging, and it was caused by someone connecting to the MUD. After I restored it, the guy connected again later and it was fine. This was a new player so I'm suspicious if he did something to make it hang, but at any rate, this is the final log leading up to the moment:

Sat Jul  4 20:04:35 2009 :: Sock.sinaddr:  166.129.*, port 49577.
Sat Jul 4 20:04:35 2009 :: Sock.sinaddr: New connection on port 49577.
Sat Jul 4 20:04:35 2009 :: [*****] BUG: ALARM CLOCK!
Sat Jul 4 20:04:35 2009 :: clearing newdesc
Sat Jul 4 20:04:35 2009 :: Registering SIGSEGV handler
Sat Jul 4 20:08:13 2009 :: Sock.sinaddr: 166.129.*, port 49588.
Sat Jul 4 20:08:13 2009 :: Sock.sinaddr: New connection on port 49588.


On line 3, the MUD detected lag, hence the alarm clock thing (stock code in SWR), then it registered the SIGSEGV handler at 5, which is code I used previously to help me capture crashes and force an emergency copyover instead. I do not know if this is perhaps a problem with the lag code detection and the sig handler perhaps? I have since stopped using the emergency copyover system and just let the mud crash (samson will love this :P), so I removed that particular bit of code but as such, I do not know what caused the MUD to hang or if the removal of that handler registering will help at all. Any input?
05 Jul, 2009, Davion wrote in the 2nd comment:
Votes: 0
Might be gethostbyaddr lag. Notice you haven't resolved from an IP yet.
05 Jul, 2009, Runter wrote in the 3rd comment:
Votes: 0
Sometimes that function on specific resolves can hang. It's something you specifically want to have threaded me thinks. Short term resolution if it becomes a problem is just storing IPs instead of the resolved string.

This doesn't really account for the crash, however. It should just wait for a resolution to complete from my experience–and it's typically momentary.
05 Jul, 2009, Banner wrote in the 4th comment:
Votes: 0
… What?
05 Jul, 2009, Cratylus wrote in the 5th comment:
Votes: 0
Banner said:
… What?


They're saying that maybe your mud is failing to do "name resolution" of
that ip address to its ip name (166.129.*.*.-host.domain.com, for example), and
that sometimes muds hang when this resolution fails to happen.

-Crat
05 Jul, 2009, Davion wrote in the 6th comment:
Votes: 0
And that you can prevent it by using threads. Take a look is socketmuds socket.c file. Look for 'pthread' and look at the function it calls. That should contain a call to 'gethostbyaddr'
05 Jul, 2009, Runter wrote in the 7th comment:
Votes: 0
Davion said:
And that you can prevent it by using threads. Take a look is socketmuds socket.c file. Look for 'pthread' and look at the function it calls. That should contain a call to 'gethostbyaddr'


Or compile in C++ and use boost::thread. It's about as easy as it gets.
05 Jul, 2009, Skol wrote in the 8th comment:
Votes: 0
Davion said:
And that you can prevent it by using threads. Take a look is socketmuds socket.c file. Look for 'pthread' and look at the function it calls. That should contain a call to 'gethostbyaddr'

Quoted for truth. Separate thread and your game doesn't lag on those hosts it can't find.
05 Jul, 2009, Banner wrote in the 9th comment:
Votes: 0
Could this be a server issue? Again, it used to show domain names before I moved to a vps but now it only shows ips.
05 Jul, 2009, Tyche wrote in the 10th comment:
Votes: 0
Banner said:
…so I removed that particular bit of code but as such, I do not know what caused the MUD to hang or if the removal of that handler registering will help at all. Any input?


Remove the signal handler so you can get a core dump you can examine.
05 Jul, 2009, Banner wrote in the 11th comment:
Votes: 0
Tyche said:
Banner said:
…so I removed that particular bit of code but as such, I do not know what caused the MUD to hang or if the removal of that handler registering will help at all. Any input?


Remove the signal handler so you can get a core dump you can examine.

Hangs don't crash, they hang.
05 Jul, 2009, Tyche wrote in the 12th comment:
Votes: 0
Then run it under gdb.
Also signal handler may indeed "hang" a system.
05 Jul, 2009, Lyanic wrote in the 13th comment:
Votes: 0
I've had similar issues in the past. For starters, my game used to hang (sometimes even resulting in a short DoS) on repeated connections from unresolvable IPs (happens a lot with IPs from China). That was before I switched to using Boost libraries on just about everything. Further, I had the issue of IPs not resolving at all when I changed servers one time. It was due to the new server being a 64-bit architecture and having compatibility issues with the old DNS library that was being used. So, it seems the solution to both is to update your implementation with this regard.
0.0/13