[ccache] ccache interrupt handling bug

Joel Rosdahl joel at rosdahl.net
Mon Aug 17 19:08:45 UTC 2015


Nadav Har'El <nyh at cloudius-systems.com> wrote:

> [...] Your patch makes ccache exit as soon as it gets the SIGINT - but the
> child compiler might still be running for a while longer. This will usually
> be fine, but I thought the user can be surprised if he sees ccache (which
> he considers to be the compiler) exit, but "ps" shows the compiler is still
> running. This would be especially annoying if some hypothetical compiler
> trapped SIGINT deliberately, and continued to run long after ccache exits.


Right, I understand where you're coming from. Thanks for clarifying your
approach.

However, letting ccache's signal handler not exit is not an option since
that would make it impossible to cancel ccache if the signal is caught when
ccache is not running a compiler. One noteworthy code path that can take
lots of time is performing cache cleanup – it can easily take many minutes
on large, cold caches. ccache's signal handler is relatively new; it was
added only recently to delete some temporary files before exiting. The
missing _exit(1) call was simply an oversight, so I just restored the
behavior to what it has been for a long time: exiting almost immediately on
a signal (i.e., not waiting for any child process to exit).

Your patch makes ccache exit as soon as it gets the SIGINT - but the child
> compiler might still be running for a while longer. This will usually be
> fine, but I thought the user can be surprised if he sees ccache (which he
> considers to be the compiler) exit, but "ps" shows the compiler is still
> running. This would be especially annoying if some hypothetical compiler
> trapped SIGINT deliberately, and continued to run long after ccache exits.


I agree that it would be preferable to wait for the compiler if it's
running. I think that the proper way to do that would be to waitpid()
inside the signal handler and then _exit().

-- Joel


More information about the ccache mailing list