Parlakisik
asked on
Process's stack and date adress
I want to find process's stack and date address when i stop it .
How can i take these variables?
I start a process with another program then this program stop other and take it's stack and data address. This is the starting point of checkpointing. I have some problems with kernel 2.2 .
Thanks.
How can i take these variables?
I start a process with another program then this program stop other and take it's stack and data address. This is the starting point of checkpointing. I have some problems with kernel 2.2 .
Thanks.
run it under gdb. You have to compile the program with the -g option. then do
gdb myprogram. You can also use gdb to attach to a running process by starting gdb, then typing 'file myprogram' then 'attach process-id'.
To tell gdb to break at a certain point
break myproblemfunction
where myproblemfunction is the name of a function you want to stop at.
then do 'run'.
The stack commands include 'bt' which allow to you backtrack in the current stack frame; 'frame n' which allows you to switch frames, where 0 is the current frame, 1 is the next frame up, etc.
The print command will show you the contents of your data variables, and the x command will let you look at any area of memory available to the program.
There's a tutorial on gdb at
http://www.cs.utah.edu/dept/old/texinfo/gdb/gdb_toc.html
gdb myprogram. You can also use gdb to attach to a running process by starting gdb, then typing 'file myprogram' then 'attach process-id'.
To tell gdb to break at a certain point
break myproblemfunction
where myproblemfunction is the name of a function you want to stop at.
then do 'run'.
The stack commands include 'bt' which allow to you backtrack in the current stack frame; 'frame n' which allows you to switch frames, where 0 is the current frame, 1 is the next frame up, etc.
The print command will show you the contents of your data variables, and the x command will let you look at any area of memory available to the program.
There's a tutorial on gdb at
http://www.cs.utah.edu/dept/old/texinfo/gdb/gdb_toc.html
ASKER
Edited text of question.
If you are trying write code to "checkpoint" a task so that it can be resumed later, there's likely to be a bit more to it than just getting the program stack. You'd also have to deal with open file descriptors and possibly other things.
In the absense of system support for checkpointing, as was found on super-computers and large mainframes, most folks who need that capability build a form of checkpointing into their task, writing the "live internal data" to file so that it can be restored when the program is restarted. You do have to be careful with respect to how you handle any open files, but it's otherwise pretty straightforward. If the task is long running (days, weeks, etc) and there's a concern that a system or power failure might result in the loss of the run, the internal "checkpoint can be done a regular intervals. It can also be arrainged for the checkpoint to occur as the result of a signal being delivered to the process.
In the absense of system support for checkpointing, as was found on super-computers and large mainframes, most folks who need that capability build a form of checkpointing into their task, writing the "live internal data" to file so that it can be restored when the program is restarted. You do have to be careful with respect to how you handle any open files, but it's otherwise pretty straightforward. If the task is long running (days, weeks, etc) and there's a concern that a system or power failure might result in the loss of the run, the internal "checkpoint can be done a regular intervals. It can also be arrainged for the checkpoint to occur as the result of a signal being delivered to the process.
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER