Is there a way to get the time a program has been actually running? It must stop when sending the STOP signal to the process and continue with CONT (in Linux)
If there is, is there a way to get it in c++?
Related
Title sums it up, I tried to use IDA Pro and x32dbg but every time I run a them, even with breakpoints it ends up forcefully stopping the debugging process and then the program executes itself, so basically I cant get to the point I want it to run before it closes.
Anyways I was wondering if there is a way to see which address a running program is at in its binary at. With the endless amount of lines, id never find what I'm looking for unless i can open the program and see where it is currently in its binary form...
We have a QProcess that runs a bash script. The script finishes properly and produces expected output, but the finished signal takes a very long time (minutes) afterward to emit. Basically, our script is generating an encrypted tarball from a list of files fed as an argument. The final bundle is sitting there on disk, intact, but Process takes a very long time to return. This is preventing our UI from moving on to the next task, because we need to ensure the script has run to completion programatically, instead of through inspection. We're not doing anything other than
connect(myProcess, SIGNAL(finished()), mySlot, SLOT(tidyUp()));
myProcess.start();
We can monitor the size of the file with Qt, and we have an estimate of its final size based on the file list we feed the script, but the script hangs around for a very long time after the file has reached its estimated size. We've inserted sync statements, but that doesn't seem to have any effect. When the script is run on the command line, the file grows, and the script stops as soon as it reaches its final size.
Why is QProcess not sending it's finished signal immediately after the script completes?
We would very much like to attach a progress bar indicating percentage of file size produced, or give some other indication of progress, but we're stumped by this behavior. We've tried using both a worker thread moved to a QThread, and running the QProcess directly in a busy loop, calling processEvents(), to no avail.
Turns out this was a problem with the commands I had in my pipe. GPG plunks out the file fairly quickly (quite variable timing, though) but then often spends quite a lot of time idling/working after the file itself has reached its final size. I'm not sure what it's doing, or why it only does on some runs of the same content, but eventually it finishes, the script completes, and I get my finished() signal delivered. I may have to put a more elaborate progress bar in place that switches to busy wait if the file size hasn't changed for a while, but it appears that Qt is working as expected here after all.
I have a shell script which runs very large simulation binaries. This becomes problematic when I want to request some output of variables in the script. For instance, when I run 10 large simulations, I want to be able to print which iteration I am on without having to wait a minute or two for the current simulation to terminate.
Currently, I am using the trap command. However, the script does not react immediately to signals but will only execute the binded function when the current iteration terminates. I will post the code if anyone needs it.
You should start threads for each large thing you're going to run. Have those threads dump results somewhere, then you have your main method free waiting to interrogate the results on the fly.
I have a user level process which is sleeping currently, by using sleep() function. I am trying to write a kernel module which can first extract the task_struct of the user process from its PID, and then can wake the process. Till date I have implemented the code for getting the task_struct from PID. But, I dont know of any function which can wake up that process. I tried wake_up_process(task_struct), though its returning 1, i.e, success in waking up the process, but the the printf() statement just after the sleep() statement of the user process is not getting executed. Will changing the state of the task_struct help? Or there's some another approach for doing the same? Please guide me further.
It is possible, but you might be going about it the wrong way. sleep() waits on a delay, and even though you could signal the process from within the kernel (essentially like kill(2) in user mode, with some non harmful signal, but something that will "kick you out" of the system call, the correct way of doing so is having the sleeping process block on a device which your kernel module exports. This way, the kernel module will have control - the process will be stuck in a read(2) call, and until your read implmentation in the module returns, the process will be stuck.
This is preferable, because the whole idea of sleeping is when you are waiting for something. When you simple sleep(xxxx) indefinitely, you're basically waiting on a time out. What more, using the device approach, you can add the file descriptor to a select(2)/poll(2) loop, as well, which makes for very elegant synchronization with other input/output descriptors.
I need to obtain an exact time of fire'ing process
(not the time of the creation of the proces which
as I know is some time later) I need to obtain
the time of 'running' program yet before its image
is loaded into memory. Is it obtainable?
Side question - all running processes in winapi
are created thru CreateProcess/Ex function
calls (Then the time I need would be the
time of calling such function) or ther are
some other ways of running processes in windows
under the hood?
GetProcessTimes() should do the trick. It returns the process creation time, which corresponds to when the kernel object was actually created irrespective of when/if the image's code is executed.