25 Mar, 2009, Openfusili wrote in the 1st comment:
Votes: 0
Heres the deal. I boot the mud as per ./startup or even just running the bin in the /area folder. and it says ** is ready to rock on port 7778.
Ok, then I try to connect with my mud client (also tried on a range of other clients.)

And it says "Connected."

But nothing shows up.

This muds been around for around 13 years, we just moved it to a new server. The old one was running CentOS, the new- Debian.

Any help would be appriciated. ALOT.
25 Mar, 2009, Kline wrote in the 2nd comment:
Votes: 0
Possibly silly question: you did re-compile after the move, correct? It sounds like you're catching an infinite loop someplace so you might want to try booting from within gdb (cd area, gdb ../src/<bin>, run <port>) so you can break execution when it freezes (ctrl-c) and see where it's happening. Did an area/pfile/something else possibly get corrupted, or mangled line endings between moving the files?
25 Mar, 2009, Openfusili wrote in the 3rd comment:
Votes: 0
We have recompiled many times.

gdb shows this…

Wed Mar 25 03:16:05 2009 :: Initializing environment..
Wed Mar 25 03:16:05 2009 :: Loading Socials..
Wed Mar 25 03:16:05 2009 :: Loading Skills..
Wed Mar 25 03:16:05 2009 :: ERROR - resolve_global_skills NULL skill: manaburn
Wed Mar 25 03:16:05 2009 :: ERROR - resolve_global_skills NULL skill: oracle blessings
Wed Mar 25 03:16:05 2009 :: ERROR - resolve_global_skills NULL skill: impale
Wed Mar 25 03:16:05 2009 :: Loading Areas..
Wed Mar 25 03:16:05 2009 :: Fixing exits..
Wed Mar 25 03:16:05 2009 :: Reseting Areas..
Wed Mar 25 03:16:05 2009 :: Loading Message Threads..
Wed Mar 25 03:16:05 2009 :: Loading Disabled List..
Wed Mar 25 03:16:05 2009 :: Loading Trivia Questions..
Wed Mar 25 03:16:05 2009 :: Loading Bans..
Wed Mar 25 03:16:05 2009 :: Loading Songs..
Wed Mar 25 03:16:05 2009 :: ** is ready to rock on port 7778.
^C
Program received signal SIGINT, Interrupt.
0xb7f4e7f2 in ?? () from /lib/ld-linux.so.2
(gdb) backtrace
#0 0xb7f4e7f2 in ?? () from /lib/ld-linux.so.2
#1 0xb7e9fa7d in select () from /lib/i686/cmov/libc.so.6
#2 0x08082b58 in game_loop (control=6) at comm.c:577
#3 0x08082153 in main (argc=1, argv=0xbfc66dd4) at comm.c:285
(gdb)

I should say that it sometimes starts, if you leave the startup script running, and kill the muds process, allowing the startup script to start it again. But it stopped doing that also. When it does start, it works great. Otherwise, I'm stuck.
25 Mar, 2009, Zeno wrote in the 4th comment:
Votes: 0
It doesn't look like it froze there. Can you connect via localhost?
25 Mar, 2009, Openfusili wrote in the 5th comment:
Votes: 0
Yeah. ^C is Ctrl-C.


^C
Program received signal SIGINT, Interrupt.
0xb7f4e7f2 in ?? () from /lib/ld-linux.so.2
(gdb) backtrace
#0 0xb7f4e7f2 in ?? () from /lib/ld-linux.so.2
#1 0xb7e9fa7d in select () from /lib/i686/cmov/libc.so.6
#2 0x08082b58 in game_loop (control=6) at comm.c:577
#3 0x08082153 in main (argc=1, argv=0xbfc66dd4) at comm.c:285
(gdb)
25 Mar, 2009, Zeno wrote in the 6th comment:
Votes: 0
What happens if you try next/step?
25 Mar, 2009, Openfusili wrote in the 7th comment:
Votes: 0
(gdb) next
Cannot find bounds of current function
(gdb) step
Cannot find bounds of current function
25 Mar, 2009, ghasatta wrote in the 8th comment:
Votes: 0
Arg, this sort of thing can be a pain to track down. My instincts are that this is not really a 'freeze' or runaway process. I think this probably has more to do with networking, but it's just a guess at this point.

Since you mentioned switching servers and OS'es, have you made sure you are linking to the appropriate versions of each system library? I.e., Are you sure that your library paths are correct for the new server? And that the headers you are including correspond to the libraries you are linking?

When you startup the game and get it to be unresponsive, how much CPU / memory utilization do you see? Use 'ps -ux' from the shell. If your game is really on a runaway loop, CPU should spike to ~100% and possibly memory as well.

Since the game seems to be starting up fine, what happens if you let it run for a while? Do you continue to see normal log messages? I suggest you set up gdb breakpoints on the functions involved in accepting a new connection and sending text to the descriptor. You might throw in some debug printouts showing what text should be sent to the client. At the least, this will help you know where to look next.

HTH.
0.0/8