Docker: Aborting an initial stack exec can turn all futher stack execs into segfaults

[nh2]

When using stack with docker, I ran and then pressed Ctrl-C:

stack exec -- ls
Downloading Docker-compatible stack executable
Downloaded stack-1.1.2.                                    
^Cuser interrupt

Following this, all my stack exec commands failed with exit code 139:

$ stack exec -- ls
$ echo $?
139

Using stack exec --verbose, I determined the path of the used stack to be ~/.stack/programs/x86_64-linux/stack-1.1.2/stack; running that directly from the host showed that it would immediately segfault. ls showed that this stack binary was only 1.9 MB in size, which is way too small. My Ctrl-C had apparently aborted the step that made stack copy itself to ~/.stack/programs/x86_64-linux/stack-1.1.2/stack, and from then on stack did not recover from this. The solution was to remove ~/.stack/programs/x86_64-linux/stack-1.1.2/stack, which made stack copy it there anew.

This is on stack-1.2.2 on Ubuntu 16.04.

I think the fix for this would be to always check that files stack puts into place are still there with the right file size, which guards against premature copy aborts with Ctrl-C or computer crashes (and is much faster than hashing the file contents, which would add a recurring startup overhead).

[snoyberg]

How about doing a cautious file write kind of thing, where you write the file to a temporary location in the same directory and then use renameFile