Mon 21 Oct 2013 08:01:04 AM UTC, comment #4:
That is not what is supposed to happen.
When you press Ctrl-C, the SIGINT handler is invoked, this is the function fatal_error_signal defined on command.c. (Please verify that the signal handler is indeed invoked.) Since on Windows SIGINT handler is run by the system in a separate thread, the first thing Make does in fatal_error_signal is suspend the main thread, so the main job is stopped in its tracks. Then it blocks inside reap_children waiting for the child processes to exit, until all the child processes finish in one way or another. (The call to reap_children is made as long as at least one job slot is still active.) On Windows, reap_children calls process_wait_for_any, which waits (using WaitForMultipleObjects) for one or more sub-process handles to become signaled,and then processes the demise of whatever process this handle belonged to.
So Make indeed does not kill the child processes, but it does wait for them all to exit, before proceeding.
Now, it could be that in your case, the linker is not run directly by Make, but by some intermediary process, and that intermediary exits without waiting for the linker. Make doesn't know anything about its grandchildren processes, only about its immediate children. Is this the case? Otherwise, I don't see how things could go wrong, please try to investigate.
Thanks.
|
Mon 21 Oct 2013 03:53:53 AM UTC, comment #3:
So it looks like from observing what happens, that subprocesses do get killed (although i haven't looked at what happens in a debugger), but they do so gently. Make doesn't wait for the process to actually be dead. Which has several interesting side effects:
- the process keeps running for a little while, and eventually dies
- it stays alive longer than it takes for make to (try to) remove the target file (xul.dll in my case). This has different possible outcomes, one of which is make failing to remove the file with a permissions denied error, the other of which is make supposedly removing the file, but the file being there after link.exe is done.
Seeing the code, it seems to me this could happen on unix as well with a process that has a long "shutdown" when receiving SIGTERM/SIGINT.
|
Mon 21 Oct 2013 12:28:18 AM UTC, original submission:
When interrupting a build with CTRL-C on a win32 build, whatever was run by make at the time keeps running. This prevents subsequent make runs to run properly, either because of file locking or because the still running commands may alter the build directory during the second build.
Note this is not a problem new to 4.0, it happened with previous releases too, as I am told.
|