|RE: [cdt-dev] Win32 spawner|
So, it turns out that Doug's fix to not use GetProcAddress() fixes my problem; the CTRL-C to the FSL debugger engine now terminates it. Matthew, thanks for your suggestion. Without it, I wouldn't have taken a second look at the code/cvs and realized I was missing Doug's fix. And, of course, Doug, a belated thanks for the fix :-)
From: cdt-dev-bounces@xxxxxxxxxxx [mailto:cdt-dev-bounces@xxxxxxxxxxx] On Behalf Of John Cortell
Sent: Thursday, July 17, 2008 12:49 PM
To: CDT General developers list.; CDT General developers list.
Subject: Re: [cdt-dev] Win32 spawner
At 09:45 AM 7/17/2008, Matthew Ballance wrote:
I've used the Win32 Job API in the past to terminate a process and its children. The Job API is only present on Win2K, Windows XP and above. Not sure if CDT is still trying to maintain support for Windows versions earlier than 2K...
The basic idea is that a Job object is created prior to calling CreateProcess using CreateJobObject(). The new process is started in the suspended state and assigned to the job object using AssignProcessToJobObject(). Then the newly-created process is resumed using ResumeThread().
When it's time to terminate the process, TerminateJobObject() is used instead of TerminateProcess(). The orignal process and any child processes are terminated.
Again, not sure if it's applicable, but an idea nonetheless...
On Thu, Jul 17, 2008 at 7:51 AM, John Cortell < john.cortell@xxxxxxxxxxxxx> wrote:
- A quick experiment and some archived emails reminded me of why I stayed away from java.lang.Runtime.exec() three years ago. It unconditionally specifies TRUE for the "inherit handles?" parameter to the Win32 CreateProcess() call. Spawner's launch logic specifies FALSE. The TRUE parameter is a deal breaker for us. Inheriting handles prevents CORBA interaction between parent and child; apparently interacting CORBA components require independent system handles.
- At 04:44 PM 7/16/2008, Schaefer, Doug wrote:
- Content-class: urn:content-classes:message
- Content-Type: multipart/alternative;
- Good question. I think it has something to do with allowing the child process to clean up. Also, TerminateProcess only kills that process, not the children of that process. But I think there is a way to do that too, but it involves a lot of code.
- Feel free to try and improve it. It probably needs it. Just make sure you don't break gdb spawning :)
- BTW, I've worked a little over the past go get everything that doesn't need the spawner's signaling capability off of it and onto Java's Runtime.exec. It seems to work better in certain situations.
- From: cdt-dev-bounces@xxxxxxxxxxx [ mailto:cdt-dev-bounces@xxxxxxxxxxx] On Behalf Of John Cortell
- Sent: Wednesday, July 16, 2008 4:36 PM
- To: CDT General developers list.
- Subject: [cdt-dev] Win32 spawner
- I've been trying to figure out why Spawner.kill() isn't killing a process for us. The "process", in our case, is our debugger engine--a Win32 executable. We use the spawner to launch it, and on shutdown, we sometimes need to abruptly kill it (if it's taking too long to shut down gracefully). Again, calling kill() on the Process object, which is a Spawner, isn't doing the trick.
- I found the answer in starter.cpp. It contains a handler which waits for the terminate event-handle to be signaled and then goes about trying to kill the process it earlier created. Problem is: it does so by sending a console CTRL-C event (unless it's a cygwin process, in which case it runs a "kill -SIGTERM" command). In our case, the process is not a cygwin process. The CTRL-C event isn't doing the trick, and I have to wonder...why aren't we just using the TerminateProcess Win32 function? We have the process handle, after all. I've coded it and it's working. I'm just scratching my head wondering why we'd try sending a CTRL-C instead.
- cdt-dev mailing list
- cdt-dev mailing list
cdt-dev mailing list
Back to the top