Samson, on gammon you mentioned that ou've valgrinded your hotboot, is there a way to make valgrind stay with the program after you hotboot? It seems to me that after you hotboot, valgrind is no longer attached to the new process. I was trying "hotboot deebug", and starting it in valgrind as "swr 4000 hotboot 5 0 0 0 -1", or whatever, but it kept stopping saying that it couldn't open the descriptor, so I removed the line for my connection in copyover.day, same thing. Any ideas? Wasn't sure how you did it.

You are correct in that Valgrind will not remain with the new process. As far as it would be concerned, you've rebooted. Which is completely accurate. A hotboot is just a fancy looking reboot where one process shuts down and another takes over. It's not possible for it to inherit the new process.

When I said I Valgrinded it, I meant I did so up to the point where the "debug" argument stops it from actually going through. That's part of why that statement is in there.

I've gone through my code, and figured out a way to valgrind the hotboot_recover. I modified the code that when the second argument is valgrind, similiar to the method of using hotboot, it will boot normally, but then calls hotboot_recover after wards, and skipps reading in player descriptors

Really. That's indeed an interesting development. So Valgrind remains in control of the code even though you rebooted the game out from under it? My mind is failing to see how it wouldn't perceive the end results as a massive memory leak when you finally do shut things down to check. What sort of results have you seen from this?

Actually, its not doing exactly after a copyover. What I'm doing is kind of a long way around, but...:

1) In a normally booted version(no valgrind), do "hotboot debug" to generate the files that would be need.

2) Shutdown mud now

3) then, I boot the mud using: "valgrind -v --leak-check=yes --show-reachable=yes --gdb-attach=yes --num-callers=10 ../src/swr 4000 valgrind "

Adding the "vagrind" argument to it. When main detects that its valgrind, as opposed to "hotboot" or nothing, it will do a normal boot, initializing port and such, and then call hotboot_recover to read all the files. It it effectively the same thing as having valgrind working across a copyover, more work and a little more processor, but it basically works accomplishes the same thing, allowing valgrind to check the hotboot_recover code, which is where I am having the problem with my own code.

Ah, I see. Yes, that would work. Thought you meant literally that it would carry past a full hotboot.

On a side note, I beleive that you CAN make valgrind stick to a hotboot mud, but at a cost. It requires that you remove the option to attach to gdb, but with " --trace-children=yes", it will stick with the child process in valgrind. If your using the valgrind option to send to a file, it will have an extension of something like "valgrind.pid20000.1". I just tested it, and it produces a seperate and distinct log from the parent program. I haven't tested this thouroughly, but lemme know if it works out for someone.