(0024645)
David Cole (manager)
2011-01-13 11:16

I would really like it to stop too... Seems to have a mind of its own.

(0024651)
James Bigler (developer)
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 (manager)
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 (manager)
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 (developer)
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 (manager)
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 (manager)
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 (manager)
2011-05-25 16:57

Not for 2.8.5 - postponing until a future release

(0030520)
Brad King (manager)
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 (developer)
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 (developer)
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 (administrator)
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.

Issue History
Date Modified	Username	Field	Change
2011-01-13 11:02	Clinton Stimpson	New Issue
2011-01-13 11:16	David Cole	Note Added: 0024645
2011-01-13 12:17	James Bigler	Note Added: 0024651
2011-01-13 13:06	David Cole	Note Added: 0024653
2011-01-17 11:48	David Cole	Assigned To	=> David Cole
2011-01-17 11:48	David Cole	Status	new => assigned
2011-01-17 11:50	David Cole	Note Added: 0024764
2011-01-17 11:50	David Cole	Status	assigned => resolved
2011-01-17 11:50	David Cole	Fixed in Version	=> CMake 2.8.4
2011-01-17 11:50	David Cole	Resolution	open => no change required
2011-01-17 13:57	Clinton Stimpson	Note Added: 0024783
2011-01-17 13:57	Clinton Stimpson	Status	resolved => feedback
2011-01-17 13:57	Clinton Stimpson	Resolution	no change required => reopened
2011-01-18 11:30	David Cole	Assigned To	David Cole => Brad King
2011-01-18 11:30	David Cole	Status	feedback => assigned
2011-01-18 11:30	David Cole	Note Added: 0024869
2011-01-18 11:56	Brad King	Note Added: 0024877
2011-04-14 14:35	David Cole	Target Version	=> CMake 2.8.5
2011-05-25 16:57	David Cole	Note Added: 0026591
2011-05-25 16:57	David Cole	Target Version	CMake 2.8.5 =>
2012-08-13 10:37	Brad King	Status	assigned => backlog
2012-08-13 10:37	Brad King	Note Added: 0030520
2015-06-19 15:33	James Johnston	Note Added: 0038958
2015-08-16 17:29	James Johnston	Note Added: 0039285
2016-06-10 14:28	Kitware Robot	Note Added: 0041777
2016-06-10 14:28	Kitware Robot	Status	backlog => resolved
2016-06-10 14:28	Kitware Robot	Fixed in Version	CMake 2.8.4 =>
2016-06-10 14:28	Kitware Robot	Resolution	reopened => moved
2016-06-10 14:31	Kitware Robot	Status	resolved => closed

Notes
(0024645) David Cole (manager) 2011-01-13 11:16	I would really like it to stop too... Seems to have a mind of its own.

(0024651) James Bigler (developer) 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 (manager) 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 (manager) 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 (developer) 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 (manager) 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 (manager) 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 (manager) 2011-05-25 16:57	Not for 2.8.5 - postponing until a future release

(0030520) Brad King (manager) 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 (developer) 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 (developer) 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 (administrator) 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.

Relationships