30 Sep, 2008, Lobotomy wrote in the 1st comment:
Votes: 0
I'm curious to know if anyone has previously solved the issue with valgrind not following a Mu* process after that Mu* performs a copyover. I have some ideas for how to resolve the issue that I'm going to try here in a moment, but I'd like to find out if anyone else has come across this problem and solved it already. At the moment I'm thinking it may be something to be done in the Mu* code itself (i.e, at the execl call), and aside from things of that nature I wonder if perhaps there's a function in valgrind itself to handle the matter as well. :thinking:
30 Sep, 2008, Davion wrote in the 2nd comment:
Votes: 0
Lobotomy said:
I'm curious to know if anyone has previously solved the issue with valgrind not following a Mu* process after that Mu* performs a copyover. I have some ideas for how to resolve the issue that I'm going to try here in a moment, but I'd like to find out if anyone else has come across this problem and solved it already. At the moment I'm thinking it may be something to be done in the Mu* code itself (i.e, at the execl call), and aside from things of that nature I wonder if perhaps there's a function in valgrind itself to handle the matter as well. :thinking:


I think you're on the right track. execl kills the previous process (hence the new pid) so I don't think it's even possible for Valgrind to follow it. I think, even, following past a copyover will be tricky, as you usually want to watch the output stream to a terminal of some sorts. If you replace the new process with one to valgrind running your MUD, you may only be able to write the output to a file instead. I'm interested to see though!
30 Sep, 2008, quixadhal wrote in the 3rd comment:
Votes: 0
I believe gdb can follow through exec, although it's been a while since I've tried. Certainly, gdb can be connected to an already running process. I guess the question is, can valgrind reconnect to a new process?
30 Sep, 2008, Zeno wrote in the 4th comment:
Votes: 0
I really don't see the point. Any mem leaks are wiped anyway when the copyover happen.
01 Oct, 2008, David Haley wrote in the 5th comment:
Votes: 0
It could be to trace memory problems – not just leaks – in the code that restores after copyover.
01 Oct, 2008, Guest wrote in the 6th comment:
Votes: 0
DavidHaley said:
It could be to trace memory problems – not just leaks – in the code that restores after copyover.


Which would be easy enough to isolate by valgrinding the entire process from bootup to shutdown, then repeating that process until you're confident that it works. Then if you still crash after copyovers you know exactly where to begin looking - in the code that's not being executed in a normal statup.

That said, what you could do is expand on something I wrote into the hotboot snippet I put up. In that if you pass "debug" as an argument to the hotboot command, it goes through the process and executes everything it needs to except it returns out of the command right before the execl() call. That means any files it wrote have been written and can be examined by hand for errors. It should be possible to write in similar code on the startup side to pretend it's doing a copyover_recover() and execute everything there except getting the old descriptors back. That method would be grindable and if you still have problems even after testing that then it should narrow things down far enough to know you've got trouble in the reconnection of the descriptors.
01 Jan, 2009, Kline wrote in the 7th comment:
Votes: 0
Hi, not to resurrect a thread, but has anybody done any work towards this? I'm actually having an issue now that only occurs after a copyover recover so I'm actively on the hunt to stick valgrind specifically on that part of my code.
01 Jan, 2009, Kline wrote in the 8th comment:
Votes: 0
So I just answered my own question about 10 minutes after this posting. We've all been sorely neglecting the –trace-children=yes option of Valgrind…Followed copyover like a champ :)
0.0/8