I am debugging a process on a web server running Linux. The process is invoked once a request is coming from a web-page. In order to debug the process, I look at the running processes list (using top), I spot the relevant process (named apache2) by it's CPU usage (quite easy, since it is usually on top of the list), and I attach the gdb session to the process id. Of course I can call the attach PID command only after the process is up.
The only problem is that this process-id-spotting takes a second or two, so I cannot stop at functions which are called during the first second or two. (The whole process takes about a minute so in most cases it is not a problem).
Is there any way of doing this automatically, so I can save these couple of seconds and start the attachment earlier?
You can attach to the parent process and catch forks. Don't forget to set follow-fork-mode child.
Related
Usually when a program is run from the Windows console, the console will wait for the process to exit and then print the prompt and wait for user input. However, if the process starts a child process, the console will still only wait for the first process to exit. It will not wait for the child as well.
Is there a way for the program to get the console to wait on another child process instead of (or as well as) the current process.
I would assume it's impossible because presumably the console is waiting on the process' handle and there's no way to replace that handle. However, I'm struggling to find any confirmation of this.
Is there a way for the program to get the console to wait on another child process instead of (or as well as) the current process.
No. As you noted, as soon as the 1st process the console creates has exited, the console stops waiting. It has no concept of any child processes being created by that 1st process.
So, what you can do instead is either:
simply have the 1st process wait for any child process it creates before then exiting itself.
if that is not an option, then create a separate helper process that creates a Job Object and then starts the main process and assigns it to that job. Any child processes it creates will automatically be put into the same job as well 1. The helper process can then wait for all processes in the job to exit before then exiting itself. Then, you can have the console run and wait on the helper process rather than the main process.
1: by default - a process spawner can choose to break out a new child process from the current job, if the job is setup to allow that.
I have a thread in some console process, whose code is not available to me. Is there a way to get notified when its state changes (e.g. becomes idle)?
Maybe hooks API or even kernel-mode API (if no other way...)?
Expansion:
I have legacy console app I have to operate in my program. The only way to interact with it, obviously, is via stdin. So I run it as new Process, and send commands to its stdin. I take some text from its stdout, but it is not entirely predictable, so I cannot rely on it in order to know when it finished its current work and ready to receive the next commands. The flow is something like this: I run it, send (e.g.) command1, wait for it to finish its work (some CPU load and some IO operations), and then issue command2, and so on, until last command. When it finished working on last command, I can close it gracefully (send exit command). The thing is that I have several processes of this console exe that are working simultaneously.
I can:
use timeouts since last stdout received - not good, because it can be a millisecond and an hour
parse stdout using (e.g.) regex to wait for expected outputs - not good... the output is wholly unexpected. It's almost random
using timers, poll its threads state and only when all of them are in wait state (and not for IO), and at least one is waiting for user input (see this) - not good either: in case I use many processes simultaneously it can create unnecessary, non-proportional burden on the system.
So I like the last option, just instead polling, I rather events fired when these threads become idle.
I hope it explains the issue well...
The context of my problem is:
I have a Windows .NET app (GUI) running as a main process.
From this (parent) process, I create a couple of sub-processes as console processes.
The main process sends data to the children processes through named pipes.
In the main app, I have a list of the sub-processes.
My probleme is that each console has a close ("x") button and can be terminated (whatever the way it is). Since I keep a list of the created consoles in my main app, I would like to know when a console is killed or exited.
My console (child process) program is simply a "main()" with a loop function that reads the pipe (and displays the data). It has no message system or whatever else that could handle a windowing "exit".
The first idea that comes to my head is to poll the sub-processes from the main app to refresh the list. But this means I have to introduce a timer or a thread that watches the consoles. I don't like the idea.
Does someone have a better idea?
WaitForSingleObject(hThread, 0) will tell you whether the thread specified in hThread argument is signaled and therefore finished. Same goes to hProcess.
Both handles of your child process are returned after CreateProcess() call. You can either close them immediately, or monitor using WaitForSingleObject.
I'm trying to get a better grasp of the inner workings of background jobs and how they improve performance.
I understand that the goal is to have the application return a response to the user as fast as it can, so you don't want to, say, parse a huge feed that would take 10 seconds because it would prevent the application from being able to process any other requests.
So it's recommended to put any operations that take more than say 500ms to execute, into a queued background job.
What I don't understand is, doesn't that just delay the same problem? I know the user who invoked that background job will get an immediate response, but what if another user comes right when that background job starts (and it takes 10 seconds to finish), wont that user have to wait?
Or is the main issue that, requests are the only thing that can happen one-at-a-time, while on the other hand a request can start while one+ background jobs are in the middle of running?
Is that correct?
The idea of a background process is that it takes care of all the long running processes.
Basically, it is an external application that is running outside of the webserver with one or several processes that handles the requests.
So, it doesn't matter if there is another user requesting a page since it the job is not occupying the webserver, the user will not have to wait for anything to finish.
If that user also do something that is being put in the background queue, then it will just stack up there until the first one is finished (or in the case where there are multiple processes handling it, as soon as there is one available).
Hope this explanation makes it a bit more clearer :)
I know Windows close kernel handles when an application crashes, but if I want to wait on this event, can I be sure it will happen in milisec or it might take a while? I would like to trigger a new function the moment one application is crashed and I'm checking if this handle is NULL but it seems like I can't get a NULL value in this case.
How long it will take may vary depending upon many factors including implementation, type of crash, etc. It might take awhile.
If you want to know when a process has crashed, you should set up a "watchdog" thread or process that waits on the application's Process Handle, using a function such as WaitForSingleObject. When the process dies, the event will be signaled and you can act accordingly.
Windows does not close handles when an application "crashes" - it closes them when the process terminates, no matter how the process terminates. By the time this happens the variables don't exist any more because the user mode address space has been shut down.
What are you trying to do?