bugmake - Bugs: bug #40322, Interrupting a build with CTRL-C...


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

Submitted by:  Mike Hommey <glandium>
Submitted on:  Mon 21 Oct 2013 12:28:18 AM UTC  
Severity:  3 - Normal Item Group:  Bug
Status:  Not A Bug Privacy:  Public
Assigned to:  None Open/Closed:  Closed
Component Version:  4.0 Operating System:  MS Windows
Fixed Release:  None Triage Status:  None

Add a New Comment(Rich Markup)

You are not logged in

Please log in, so followups can be emailed to you.


( Jump to the original submission)

Fri 29 Nov 2013 09:08:29 AM UTC, comment #8:

Please close. I /think/ all the issues i've had so far are due to our intermediate processes not handling things well. I'll reopen if it turns out there is something wrong with make.

Mike Hommey <glandium>
Fri 29 Nov 2013 08:34:42 AM UTC, comment #7:

Any news on this one? Should I close it?

Eli Zaretskii <eliz>
Project Member
Thu 07 Nov 2013 05:28:40 AM UTC, comment #6:

Any news on this? I don't want to leave a bug report that cannot be reproduced for prolonged periods of time.


Eli Zaretskii <eliz>
Project Member
Tue 22 Oct 2013 04:50:06 AM UTC, comment #5:

As a matter of fact, we do have an intermediate process for those commands. I'll double check what's actually happening.

Mike Hommey <glandium>
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.


Eli Zaretskii <eliz>
Project Member
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.

Mike Hommey <glandium>
Mon 21 Oct 2013 03:00:27 AM UTC, comment #2:

The typical case where this happens is when link.exe is running to link xul.dll in a Firefox build. I'll check at some other random places.
I'll also check what happens with the commands.c code in a debugger.

Mike Hommey <glandium>
Mon 21 Oct 2013 02:53:31 AM UTC, comment #1:

This doesn't happen for me. Does it happen for you always, or just with some Makefile's? Can you show an example of a Makefile and a session where Ctrl-C does not interrupt the Make run?

There's special code in Make to handle the Ctrl-C situation (look for SuspendThread in commands.c). Perhaps it somehow doesn't do its job in your case?

Eli Zaretskii <eliz>
Project Member
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.

Mike Hommey <glandium>


(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:

No files currently attached


Depends on the following items: None found

Items that depend on this one: None found


Carbon-Copy List
  • -email is unavailable- added by eliz (Posted a comment)
  • -email is unavailable- added by glandium (Submitted the item)

    Do you think this task is very important?
    If so, you can add your encouragement to it.
    This task has 0 encouragements so far.

    Only logged-in users can vote.


    Please enter the title of George Orwell's famous dystopian book (it's a date):



    Follow 2 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    Fri 29 Nov 2013 11:09:47 AM UTC eliz StatusNone => Not A Bug
        Open/ClosedOpen => Closed

    Back to the top

    Powered by Savane 3.3