RE: [cdt-core-dev] Problem cancelling a launch

["James Langley" <jlangley@xxxxxxxxxx>]

Title: Message

I’ve tried using Runtime.exec() to do the same thing and that means that I can cancel successfully, but I don’t think that a CTRL-C gets sent to the shell and so there’s no opportunity to handle any cleanup.  I’d like to use the ProcessFactory approach if possible as I believe that CTRL-C is the whole reason that the ProcessFactory approach exists.

 

Do you use the trap command in your scripts, because if I use the trap command to exit and make sure to run any processes in the background in the script and then wait for them to finish I can kill the script successfully at the command prompt.  If I don’t do that, then even a CTRL-C at the command prompt doesn’t kill the child process.

 

James

 

-----Original Message-----
From: cdt-core-dev-admin@xxxxxxxxxxx [mailto:cdt-core-dev-admin@xxxxxxxxxxx] On Behalf Of Lott, Jeremiah
Sent: 23 July 2004 16:21
To: cdt-core-dev@xxxxxxxxxxx
Subject: RE: [cdt-core-dev] Problem cancelling a launch

 

We had similar problem using ProcessFactory in CDT 1.2.0.  We started using Runtime.exec(...) in all cases where we didn't explicitly need the extra features provided by ProcessFactory and started getting better results.  However, we will still sometimes get the behavior that the parent process dies and the UI control returns to the user, but the child process continues to run in the background.  These problems seem to happen much more on windows (with Cygwin) than on Linux.

 

  Jeremiah Lott

  TimeSys Corporation

-----Original Message-----
From: James Langley [mailto:jlangley@xxxxxxxxxx]
Sent: Friday, July 23, 2004 10:57 AM
To: cdt-core-dev@xxxxxxxxxxx
Subject: [cdt-core-dev] Problem cancelling a launch

Hi,

 

I’m having some problems with process termination under CDT that I hope someone can help with.  This might be a candidate for a bugzilla, but I thought I’d ask here first.

 

As part of our launch process for a remote hardware target, we need to download the elf file to the board.  This is accomplished by a shell script which does some processing and then launches an executable to download to the board.  So we have a step in our launch which runs the download script.  If the elf file is large, the download can take some time, so it would be nice to be able to cancel the process.  Here’s a snippet of code from the launch configuration delegate which should allow for cancelling:

 

Process process = exec(runCommandArray, getEnvironmentProperty(config), currentWorkingDir);

IProcess downloadProcess = DebugPlugin.newProcess(launch, process, renderProcessLabel(getRunLabel()));

          

int total_work = 0;

 

while (!downloadProcess.isTerminated())

{

     if (monitor.isCanceled())

     {

           if (downloadProcess.canTerminate())

                 downloadProcess.terminate();

           return false;

     }

     if (total_work <= 90)

           monitor.worked(10);

     try

     {

           Thread.sleep(1000);

     }

     catch (InterruptedException e)

     {}

}

 

The runCommandArray consists of the path for sh, then the name of the script and then the arguments for the script.  The exec command ends up running the following line of code:

 

ProcessFactory.getFactory().exec(cmdLine, envp, workingDirectory);

 

When the script is run from the command line, it can be cancelled successfully and it cleans up its child processes.  However, when run from eclipse, the call to terminate() hangs until the download program (which was launched by the script) has finished.  From debugging, it looks as though the culprit is the call to:

 

((SpawnerInputStream)getErrorStream()).close();

 

in the destroy method of the Spawner.

 

Sorry for the lengthy description of the problem, but is there some part of the cancel process that I’m missing, or is there some kind of problem with the Spawner that means that it doesn’t terminate processes properly?  I’m running on Windows XP and the problem seems to exist in CDT 1.2.1 and 2.0.  If a bugzilla would be more appropriate than a discussion in this mailing list, feel free to let me know and I’ll submit the problem there.

 

Thanks in advance,

 

 

James Langley
Senior Software Engineer
Altera European Technology Centre
Holmers Farm Way
High Wycombe
Bucks HP12 4XF
United Kingdon
http://www.altera.com