Description of problem: When trying to interrupt a long compilation using ccache with control-C, it doesn't work correctly. The first interrupt appears to be ignore but what it really does is to restart (!) the compilation. The second interrupt works as expected. While this might look like a minor annoyance (just press control-C again to kill it...), it causes more serious problems when the compiler is used from a make system like "make" or especially "ninja-build", and causes control-C to not stop the build until all compilation processes are done. Also, this problem is especially annoying because merely installing the "ccache" package replaces all your compilers with ccache, so a user might be using ccache without even noticing, so every place ccache deviates from normal compiler behavior is really unwelcome. I reported this bug, and a 4-line patch for it, to upstream, but so far they've ignored it: https://lists.samba.org/archive/ccache/2015q3/001311.html Version-Release number of selected component (if applicable): Ccache 3.2.2 How reproducible: Consider the following C++ program from hell that takes 13 seconds to compile on my machine (change "27" to a higher number to make it even slower): template <int TreePos, int N> struct FibSlow_t { enum { value = FibSlow_t<TreePos, N - 1>::value + FibSlow_t<TreePos + (1 << N), N - 2>::value, }; }; template <int TreePos> struct FibSlow_t<TreePos, 2> { enum { value = 1 }; }; template <int TreePos> struct FibSlow_t<TreePos, 1> { enum { value = 1 }; }; static int s_value = FibSlow_t<0, 27>::value; Compile this with: "CCACHE_RECACHE=1 ccache g++ -c example.cc" Expected results: pressing control-C stops the compilation immediately. Actual results: * The first control-C is seemingly ignored and compilation continues to the end. But if you check what really happened, the compilation *was* killed (the SIGINT was sent to it as well), but ccache decided to restart it! * If you press control-C for a second time, it works (stops compilation immediately).
Ccing upstream here as well. It's been only a few days since your post, I'm sure they'll take a look at it time permitting.
Hi, Thanks for the bug report. This will be fixed in ccache 3.2.3. > I reported this bug, and a 4-line patch for it, to upstream, but so far > they've ignored it Using the word "ignored" to say "have not yet had time to answer" is technically correct but it certainly doesn't make me more motivated to fix it in my free time.
ccache-3.2.3-1.fc23 has been submitted as an update for Fedora 23. https://admin.fedoraproject.org/updates/ccache-3.2.3-1.fc23
ccache-3.2.3-1.fc22 has been submitted as an update for Fedora 22. https://admin.fedoraproject.org/updates/ccache-3.2.3-1.fc22
Package ccache-3.2.3-1.fc22: * should fix your issue, * was pushed to the Fedora 22 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing ccache-3.2.3-1.fc22' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2015-13702/ccache-3.2.3-1.fc22 then log in and leave karma (feedback).
ccache-3.2.3-1.fc23 has been pushed to the Fedora 23 stable repository. If problems still persist, please make note of it in this bug report.
ccache-3.2.3-1.fc22 has been pushed to the Fedora 22 stable repository. If problems still persist, please make note of it in this bug report.