hDuplicateTo001 fragile under CI
In this build (x86_64-linux-deb9-debug
job) the hDuplicateTo001
test failed with:
Wrong exit code for hDuplicateTo001(threaded2)(expected 0 , actual 1 )
Stderr ( hDuplicateTo001 ):
hDuplicateTo001: tmp: hDuplicateTo: resource busy (Device or resource busy)
*** unexpected failure for hDuplicateTo001(threaded2)
This is the only time I have seen this failure.
I believe hDuplicateTo
ultimately calls dup2
(see GHC.IO.Handle.dupHandleTo
). The manpage for dup2
claims that this error might be returned if:
EBUSY (Linux only) This may be returned by dup2() or dup3() during a race condition with open(2) and dup().
In other words, we asked the kernel to make the file descriptor dest
a duplicate of handle src
, but while this operation was underway another thread allocated dest
.
It's rather unclear what to do here. I can see how this would happen but it's quite unclear what we can do about this. It seems to me like it is nearly impossible to use this operation in the threaded runtime, given how little control you have over when and how fds are allocated.
I'm going to disable this test in the threaded way.