Memory leaks, possibly?

My muds has recently had a flood of players, and its bringing out the less obvious bugs/leaks. I have four that I currently know of, one in act_string, one in move_char, one with linking problems, and one in my copyover. Perhaps people have come across these before.

The one that perplexes me most, because I can't see a core, cause its not crashing, but basically it seems that people/objs are not linking properly into rooms. I can be standing in the same room as someone(we were on the phone at the time, so we were able to confirm this), but were not able to see or hear each other through say/look, and we were not in the same list, apparently, cause we got different list with rstat. I understand that this may be a know problem, perhaps people have heard of it?

The problem seems to be, in regards to copyover, that while writing the descriptors to the file, they are somehow becoming corrupt. Could someone perhaps a way of testing this? It seems I am unable to recreate these problem with any great certainty.

The problem in act_string is here:

At the moment I am incredibly tired, so if any of this doesn't make sense, please forgive me. However, if anyone can suggest something that might help, I would be eternally greatful.

Can someone explain to me exactly what copyover is and why it is so wonderful? If I am right, it is a way of recompiling the server without losing connected players, is that it? The copyover code somehow saves where everyone is, what their connection descriptor is, and so on, stop the current executable, starts a new one, the new one reads everything back, and the players stay connected during all this? Is that it? I think in Dawn Of Time they call that "hot reboot".

It sounds a nice idea, although perhaps a bit complex. But does it work well enough to justify itself? I seem to be reading post after post about how the MUD crashes after a hot reboot, or doesn't work well, so it has to be rebooted anyway.

If the hot reboot (copyover) is really so flaky, is there any real advantage to it?

It seems to me that the sensible thing is to simply reboot the server late at night (or in the middle of the day, or whenever it is that least players are on), after an announcement to that effect so players can save there stuff, or loot corpses or whatever they want to do.

If you have the "hot reboot" followed directly by a crash, or another reboot an hour later because of things like described in this post (things not linking properly, memory leaks) then you may as well have done a normal reboot in the first place.

The SMAUG code as originally written shuts itself down every 24 hours anyway (hence the startup script) so unless you are really keen to install a new version of the server more frequently than once every 24 hours, I can't really see the point of all this copyover stuff.

Yeah, however the version that I am using generally help preserve the descriptors after crashes as well, plus it exports a core for me to debug, which is usually helpful. It also perfectly preserves the state in which the mud is at(keeps objects, mobs, ships(SWR), players, time, ticks, etc) so that no one notices when we do crash/copyover. And we do actually do several a day, be it really small crash fixes(I forgot a smash_tilde, at one point), or when I am implementing a new system(like olc channels) and the other coders are as well(arena code). We do end up doing several a day, and I find it incredibly useful. Copyover is pretty much the exact same as hot reboot, as far as I know. To me, my other coders, and our players, its very useful.

The linking problem, however, doesn't seem to be associated with copyover at all. Its something entirely of itself.

Copyover is infinitely useful in my situation as well. Especially if I happen to be doing modifications from work. Not having to type my login over again in putty is quite nice. Of course, I'm sure it goes without saying that my copyover routine has been debugged and doesn't result in crashing when used. Mine also preserves partial world state when used.

What I however don't do is rely on it as a means of crash recovery. I recently instituted my own take on that which some may see as far more radical: intercept signal 11, log a backtrace, then reenter game_loop without a reboot. Of any kind. The signal handlers are not initialized until after boot_db is run though. That could turn ugly fast.

I tend to view unmodified copyover as next to useless. A reboot is a reboot. If you don't preserve some of your world data, why bother? People don't tend to like sudden restarts. Especially if they just happened to kill the superbaddy, only to lose the loot because they didn't have time to pick it up.

And of course I don't even want to get into issues of trying to use it in Windows. *shudder*

Oh, and to answer Greven's original question:

Concentrate your efforts on your copyover routine. I've done extensive Valgrinding of the Smaug code and none of the areas you mention have had indications of leakage. I ran my main port for a whole week with it. Plenty of players came and went, mobs roamed, imms logged on and off, intermud chatting, the whole bit. act_string and move_char came out clean.

What you're seeing likely isn't a memory leak. It's link corruption, which is a whole other beast and is hard as hell to find. You're on the right track to suspect move_char, since it's one of the most common places to hose something. I'd suggest you try looking for any instances in your code where you might have done something like ch->in_room = newroom, without going through char_from_room and char_to_room.

I took your suggestion and hunted ch->in_room being set, but I only found 4 instances: one if do_hell, one in fight, one in handler, and one in shops. They didn't turn up squat, unfortunately. My guess is that we recently added an area->first_char to make running through of characters a little easier, but doesn't seem to be a problem with it. We're currently working on code to free everything that we assign, to try to track down lost links with valgrind, but the problem I am having is that I do not have valgrind available to run through my main port, and I can't seem to recreate the problems with out players running around. I do have it available on a seperate server that one of our coders runs.

So, I guess, my next questions is: is there any way that I could run the mud on my local host using valgrind on the other computer. I dunno, forwarding connections possibly? Or accessing the program remotely, I'm not sure if someone might know of a way to do this. Any help would be appreciated. Thanks alot guys.