MantisBT - CMake
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0011692CMakeCMakepublic2011-01-13 11:022016-06-10 14:31
ReporterClinton Stimpson 
Assigned ToBrad King 
PrioritynormalSeverityminorReproducibilityalways
StatusclosedResolutionmoved 
PlatformWindowsOSOS Version7
Product Version 
Target VersionFixed in Version 
Summary0011692: interrupt batch build doesn't stop visual studio
DescriptionI ran
cmake --build . --config Debug
from the command line with a Visual Studio generator being used.

If I hit ctrl-c to stop the build, the cmd prompt comes back, but Visual Studio is still building in the background with no output coming to the console anymore.
Process Explorer shows its still going as its own top level process.

I'd like it to really stop.
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Files
Issue History
Date ModifiedUsernameFieldChange
2011-01-13 11:02Clinton StimpsonNew Issue
2011-01-13 11:16David ColeNote Added: 0024645
2011-01-13 12:17James BiglerNote Added: 0024651
2011-01-13 13:06David ColeNote Added: 0024653
2011-01-17 11:48David ColeAssigned To => David Cole
2011-01-17 11:48David ColeStatusnew => assigned
2011-01-17 11:50David ColeNote Added: 0024764
2011-01-17 11:50David ColeStatusassigned => resolved
2011-01-17 11:50David ColeFixed in Version => CMake 2.8.4
2011-01-17 11:50David ColeResolutionopen => no change required
2011-01-17 13:57Clinton StimpsonNote Added: 0024783
2011-01-17 13:57Clinton StimpsonStatusresolved => feedback
2011-01-17 13:57Clinton StimpsonResolutionno change required => reopened
2011-01-18 11:30David ColeAssigned ToDavid Cole => Brad King
2011-01-18 11:30David ColeStatusfeedback => assigned
2011-01-18 11:30David ColeNote Added: 0024869
2011-01-18 11:56Brad KingNote Added: 0024877
2011-04-14 14:35David ColeTarget Version => CMake 2.8.5
2011-05-25 16:57David ColeNote Added: 0026591
2011-05-25 16:57David ColeTarget VersionCMake 2.8.5 =>
2012-08-13 10:37Brad KingStatusassigned => backlog
2012-08-13 10:37Brad KingNote Added: 0030520
2015-06-19 15:33James JohnstonNote Added: 0038958
2015-08-16 17:29James JohnstonNote Added: 0039285
2016-06-10 14:28Kitware RobotNote Added: 0041777
2016-06-10 14:28Kitware RobotStatusbacklog => resolved
2016-06-10 14:28Kitware RobotFixed in VersionCMake 2.8.4 =>
2016-06-10 14:28Kitware RobotResolutionreopened => moved
2016-06-10 14:31Kitware RobotStatusresolved => closed

Notes
(0024645)
David Cole   
2011-01-13 11:16   
I would really like it to stop too... Seems to have a mind of its own.
(0024651)
James Bigler   
2011-01-13 12:17   
I've also seen this while building in the IDE. For whatever reason VS doesn't think it needs to stop and will finish all the currently building projects (and not just the individual build rules).
(0024653)
David Cole   
2011-01-13 13:06   
Ah... that's right. I've seen this in the VS IDE, too. Thanks for reminding us of that, James.
(0024764)
David Cole   
2011-01-17 11:50   
There would appear to be not much that cmake/ctest can do about this. Since the builds cannot even be stopped by using Ctrl+Break in the Visual Studio GUI, I'm not sure there's anything we could even try to do that would be effective here.

The best thing to do, I guess, which I do on at least a weekly basis personally, is to keep "Process Explorer" handy, and to launch it a kill stuff manually when necessary.

If somebody has a flash of brilliance and a good suggestion for how we could overcome this, then please feel free to re-open this issue and attach a note.

Thanks...
(0024783)
Clinton Stimpson   
2011-01-17 13:57   
I actually suspect an issue with how win32 child processes are handled.
"cmake --build" has visual studio as a child process, so I'm wondering why cmake doesn't stop child processes, like it does on Unix. Also, this orphaned Visual Studio does stop itself when the compile is complete and it disappears from process explorer. So a weekly cleanup won't do anything.

I've also seen this behavior with ctest when there are several long tests running and ctest is interrupted with ctrl-c. The test executables are orphaned and still run to completion. I've not seen this behavior on Unix.
(0024869)
David Cole   
2011-01-18 11:30   
Brad,

Should all child processes be killed immediately when Ctrl+C is used on a "cmake --build ." invocation, or is it reasonable that any pending sub-processes run to completion first...?
(0024877)
Brad King   
2011-01-18 11:56   
It would be nice if Ctrl-C worked at Windows prompts. It will take some research to figure out how. On UNIX we get it for free because of the way process groups and delivery of the user-break signals work.

Perhaps SetConsoleCtrlHandler can help:

  http://msdn.microsoft.com/en-us/library/ms686016%28v=vs.85%29.aspx [^]
(0026591)
David Cole   
2011-05-25 16:57   
Not for 2.8.5 - postponing until a future release
(0030520)
Brad King   
2012-08-13 10:37   
Sending issues I'm not actively working on to the backlog to await someone with time for them.

If an issue you care about is sent to the backlog when you feel it should have been addressed in a different manner, please bring it up on the CMake mailing list for discussion. Sign up for the mailing list here, if you're not already on it:

 http://www.cmake.org/mailman/listinfo/cmake [^]

It's easy to re-activate a bug here if you can find a CMake developer or contributor who has the bandwidth to take it on.
(0038958)
James Johnston   
2015-06-19 15:33   
Some people above have speculated that the issue may be Visual Studio specific, due to failure of Ctrl+C to stop building projects in the Visual Studio IDE. (i.e. without CMake involved at all). I've seen this also happen in Visual Studio.

However, I think it is not Visual Studio-specific. I am observing this with CMake 3.3.0-rc1 and multiple generators: Ninja, Borland Makefiles, and also Visual C++ 2008 (Express).

It's really annoying!
(0039285)
James Johnston   
2015-08-16 17:29   
To clarify my previous observations, I think I was somewhat confused as I was using ExternalProject_Add with a different generator from the root project. I've since done some research into the matter.

Proper Ctrl+C operation requires cooperation from all the processes involved. CMake 3.4 will no longer exit if an immediate child process is still running. However, if that immediate child process exits and there are grand-children still running, CMake will still exit "prematurely."

For a build invoked with cmake --build, in practice this means that when Ctrl+C is pressed:

1. CMake must wait for the make tool to exit.
2. The make tool must wait for the invoked compiler/linker to exit.
3. The compiler/linker tool would process Ctrl+C and exit immediately.

CMake 3.4 will introduce support for waiting for immediate children to exit. A brief survey of the following generators as of 8/16/2015 that I've tested shows which ones will also properly wait:

 * Waits for children to exit on Ctrl+C: Ninja 1.5, GNU Make 4.1
 * Does not wait for children to exit: NMake (from Visual C++ 2008), JOM 1.0.16
 * Waits for children to exit on Ctrl+C, and also prevents Ctrl+C from being passed on to further child processes (i.e. new process group): MSBuild (e.g. Visual C++ 2010)
(0041777)
Kitware Robot   
2016-06-10 14:28   
Resolving issue as `moved`.

This issue tracker is no longer used. Further discussion of this issue may take place in the current CMake Issues page linked in the banner at the top of this page.