Login
User Name:

Password:



Register
Forgot your password?
Vote for Us!
auth_update crash
Dec 23, 2017, 10:15 pm
By Remcon
check_tumble
Dec 18, 2017, 7:21 pm
By Remcon
parse description bug
Dec 15, 2017, 10:08 pm
By Remcon
Couple bugs
Dec 12, 2017, 5:42 pm
By Remcon
Bug in disarm( )
Nov 12, 2017, 6:54 pm
By GatewaySysop
LoP 1.46
Author: Remcon
Submitted by: Remcon
LOP 1.45
Author: Remcon
Submitted by: Remcon
LOP Heroes Edition
Author: Vladaar
Submitted by: Vladaar
Heroes sound extras
Author: Vladaar
Submitted by: Vladaar
6Dragons 4.3
Author: Vladaar
Submitted by: Vladaar
Users Online
CommonCrawl

Members: 0
Guests: 7
Stats
Files
Topics
Posts
Members
Newest Member
478
3,708
19,242
612
Jacki72H
Today's Birthdays
There are no member birthdays today.
Related Links
» SmaugMuds.org » General » Smaug Snippets » Hotboot and valgrind
Forum Rules | Mark all | Recent Posts

Hotboot and valgrind
< Newer Topic :: Older Topic > Can it be done?

Pages:<< prev 1 next >>
Post is unread #1 Mar 23, 2004, 11:26 pm
Go to the top of the page
Go to the bottom of the page

Greven
Magician
GroupMembers
Posts204
JoinedMar 5, 2005

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.
       
Post is unread #2 Mar 24, 2004, 4:12 am
Go to the top of the page
Go to the bottom of the page

Samson
Black Hand
GroupAdministrators
Posts3,639
JoinedJan 1, 2002

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.
       
Post is unread #3 Mar 24, 2004, 2:21 pm
Go to the top of the page
Go to the bottom of the page

Greven
Magician
GroupMembers
Posts204
JoinedMar 5, 2005

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
       
Post is unread #4 Mar 24, 2004, 4:24 pm
Go to the top of the page
Go to the bottom of the page

Samson
Black Hand
GroupAdministrators
Posts3,639
JoinedJan 1, 2002

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?
       
Post is unread #5 Mar 25, 2004, 12:30 am
Go to the top of the page
Go to the bottom of the page

Greven
Magician
GroupMembers
Posts204
JoinedMar 5, 2005

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.
       
Post is unread #6 Mar 28, 2004, 3:24 pm
Go to the top of the page
Go to the bottom of the page

Samson
Black Hand
GroupAdministrators
Posts3,639
JoinedJan 1, 2002

Ah, I see. Yes, that would work. Thought you meant literally that it would carry past a full hotboot.
       
Post is unread #7 Mar 28, 2004, 5:40 pm
Go to the top of the page
Go to the bottom of the page

Greven
Magician
GroupMembers
Posts204
JoinedMar 5, 2005

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.
       
Pages:<< prev 1 next >>