cabal-install doesn't respect ^C #6322
Comments
|
|
I remember that we already had some code/tickets related to this, but don't remember where. @dcoutts? |
…6322) The concrete bug is that `try` catches asynchronous exceptions, preventing `withAsync` from interrupting it when its `body` action finishes prematurely. This manifests during `cabal build` when hitting Ctrl-C during download, e.g.: 1. Ctrl-C interrupts a curl process 2. This interrupt is converted into a UserInterrupt exception via the process package's delegate_ctlc functionality. 3. UserInterrupt bubbles up through `fetchPackage`, is caught by the `try` (fine) and writen to the result mvar. Meanwhile, `fetchPackage` continues its loop, starting to fetch the next package. 4. Some `rebuildTarget` is waiting for the interrupted download; `waitAsyncFetchPackage` rethrows UserInterrupt in that thread. 5. UserInterrupt bubbles up through `collectJob`, `execute`, the `body` action. 6. `withAsync`'s finalizer cancels the `fetchPackages` async. 7. The `fetchPackages` async receives the AsyncCancelled exception while fetching the next package (see 3. above). This interrupts the download action (it shouldn't matter whether we happen to be running curl again or not), and AsyncCancelled bubbles up through `fetchPackage`, is caught by the `try` (not fine!) and written to the mvar. But no-one is reading that mvar anymore because the build job already aborted (step 5), and that AsyncCancelled exception is lost. 8. `fetchPackages` keeps doing its thing, exiting eventually.
…6322) The concrete bug is that `try` catches asynchronous exceptions, preventing `withAsync` from interrupting it when its `body` action finishes prematurely. This manifests during `cabal build` when hitting Ctrl-C during download, e.g.: 1. Ctrl-C interrupts a curl process 2. This interrupt is converted into a UserInterrupt exception via the process package's delegate_ctlc functionality. 3. UserInterrupt bubbles up through `fetchPackage`, is caught by the `try` (fine) and writen to the result mvar. Meanwhile, `fetchPackage` continues its loop, starting to fetch the next package. 4. Some `rebuildTarget` is waiting for the interrupted download; `waitAsyncFetchPackage` rethrows UserInterrupt in that thread. 5. UserInterrupt bubbles up through `collectJob`, `execute`, the `body` action. 6. `withAsync`'s finalizer cancels the `fetchPackages` async. 7. The `fetchPackages` async receives the AsyncCancelled exception while fetching the next package (see 3. above). This interrupts the download action (it shouldn't matter whether we happen to be running curl again or not), and AsyncCancelled bubbles up through `fetchPackage`, is caught by the `try` (not fine!) and written to the mvar. But no-one is reading that mvar anymore because the build job already aborted (step 5), and that AsyncCancelled exception is lost. 8. `fetchPackages` keeps doing its thing, exiting eventually. Note that this change affects both instances of `try` in this story: `UserInterrupt` is also an asynchronous exception, so after the change the `UserInterrupt` takes a different path from step 3. That appears to be fine, though.
|
I might have a fix for this in #7929, but it's a bit unclear if there's a different bug. I see the described behaviour, but only when there are (multiple) packages to be downloaded, and I try to interrupt during download. I've managed to reproduce that bug, and fix it in the PR. From the description and terminal log here it's unclear whether downloading was involved. |
|
@robx I think we should close it, do you agree? I just tried to Ctrl-C at various stages while building |
|
Yes, that sounds good to me -- this report is Linux-specific, and to the best of my knowledge the issue is fixed there. (I think the fix didn't make it into 3.8, but should be there in current master and 3.10.) I'll close, of course feel free to reopen this if it resurfaces, or if we should wait for the 3.10 release before closing the issue. |
|
I was trying on 3.8 by the way. And #7921 definitely got in 3.8. |
Describe the bug
One have to ^C a lot to make cabal cancel. This is super annoying
To Reproduce
cabal v2-buildsomething with plenty (fresh to build) dependencies. Try to ^C build right away. It won't. (on Linux).Expected behavior
cabalshould cancel promptly.System information
Additional context
E.g. when built through
make, make seems to forward ^C, and then dies itself, leaving "downloading" cabal on the background. That's bad.Feels like some missing
bracketsomewhere.The text was updated successfully, but these errors were encountered: