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?
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.
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.
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'
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.
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.
…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.
…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.
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.
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?