bug-make
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[bug #40322] Interrupting a build with CTRL-C doesn't kill subprocesses


From: Eli Zaretskii
Subject: [bug #40322] Interrupting a build with CTRL-C doesn't kill subprocesses
Date: Mon, 21 Oct 2013 08:01:04 +0000
User-agent: Mozilla/5.0 (Windows NT 5.1; rv:24.0) Gecko/20100101 Firefox/24.0

Follow-up Comment #4, bug #40322 (project make):

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.


    _______________________________________________________

Reply to this item at:

  <http://savannah.gnu.org/bugs/?40322>

_______________________________________________
  Message sent via/by Savannah
  http://savannah.gnu.org/




reply via email to

[Prev in Thread] Current Thread [Next in Thread]