Opened 3 years ago
Last modified 2 months ago
#7325 new bug
threadDelay mistreats minBound and maxBound in some configurations
Description
threadDelay currently treats minBound and maxBound incorrectly in some cases. This breaks the following idiom (as seen in the async package):
forever (threadDelay maxBound)
On Linux (Ubuntu 10.04 64-bit) without -threaded, threadDelay maxBound returns immediately. For lower numbers on the same order of magnitude, it behaves non-deterministically. For example, given this program:
import Control.Concurrent import Control.Monad main = forM_ [6244222868950683224..] $ \i -> do print i threadDelay i
threadDelay returns immediately in some cases but not in others. If I compile and run it in bash like this:
ghc-7.6.1 -fforce-recomp threadDelay-maxBound.hs ; ./threadDelay-maxBound
The bug usually appears, but if I run it like this:
ghc-7.6.1 -fforce-recomp threadDelay-maxBound.hs ./threadDelay-maxBound
The bug does not appear (threadDelay blocks like it should). Thus, the program is affected by a very subtle difference in how it is invoked. Perhaps it is sensitive to file descriptor numbers.
On Windows without -threaded, threadDelay maxBound seems to work, but threadDelay minBound blocks rather than returning immediately.
Change History (8)
comment:1 Changed 3 years ago by tibbe
- Cc johan.tibell@… added
comment:2 Changed 3 years ago by simonmar
- difficulty set to Unknown
- Milestone set to 7.6.2
- Priority changed from normal to high
comment:3 Changed 10 months ago by thoughtpolice
- Milestone changed from 7.6.2 to 7.10.1
Moving to 7.10.1.
comment:4 Changed 10 months ago by kim
- Cc simonmar added
On OSX 10.9 and ghc 7.8.x I'm seeing the following behaviour:
- threadDelay minBound returns immediately (with or without -threaded )
- threadDelay maxBound without -threaded , the program terminates with:
maxbound: select: Invalid Argument(similar to #6019)
- threadDelay maxBound with -threaded prints on stderr:
maxbound: c_poll: invalid argument (Invalid argument) maxbound: ioManagerWakeup: write: Bad file descriptorand then appears to hang. When running it on a different thread, which is then killed from the main thread after some time, the following line is printed in after the above:
maxbound: ioManagerWakeup: write: Bad file descriptorThe program makes no progress after the thread got killed. Curiously, on another machine with same OS and ghc versions but more cores, the program crashes instead of hangs.
- as described by the reporter, for some values < maxBound but in the same order of magnitude, the errors disappear, but for others they don't.
Please do let me know if providing dtruss output would be helpful.
comment:5 Changed 10 months ago by AndreasVoellmy
- Cc AndreasVoellmy added
comment:6 Changed 7 months ago by Feuerbach
Another report of this bug:
comment:7 Changed 4 months ago by thoughtpolice
- Milestone changed from 7.10.1 to 7.12.1
Moving to 7.12.1
See #6019 for the maxBound problem. I haven't investigated the minBound problem yet.