Opened 3 years ago

Last modified 3 days ago

#7325 new bug

threadDelay mistreats minBound and maxBound in some configurations

Reported by: joeyadams Owned by:
Priority: high Milestone: 7.12.1
Component: Runtime System Version: 7.6.1
Keywords: Cc: johan.tibell@…, simonmar, AndreasVoellmy
Operating System: Windows Architecture: Unknown/Multiple
Type of failure: Incorrect result at runtime Test Case: base/tests/T8089
Blocked By: Blocking:
Related Tickets: #9722 Differential Revisions:

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 (9)

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

See #6019 for the maxBound problem. I haven't investigated the minBound problem yet.

comment:3 Changed 13 months ago by thoughtpolice

  • Milestone changed from 7.6.2 to 7.10.1

Moving to 7.10.1.

comment:4 Changed 12 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 descriptor
    
    and 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 descriptor
    
    The 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.

(similar to #5544)

  • 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.

Last edited 12 months ago by kim (previous) (diff)

comment:5 Changed 12 months ago by AndreasVoellmy

  • Cc AndreasVoellmy added

comment:6 Changed 10 months ago by Feuerbach

comment:7 Changed 6 months ago by thoughtpolice

  • Milestone changed from 7.10.1 to 7.12.1

Moving to 7.12.1

comment:8 Changed 5 months ago by thomie

comment:9 Changed 3 days ago by thomie

  • Operating System changed from Unknown/Multiple to Windows
  • Test Case set to base/tests/T8089

The issue around threadDelay maxBound on OS X is I think fixed. At least, #8089 added a test for it, which is supposedly passing on OS X.

That makes this a Windows only problem now.

Unexpected failures:

. T8089 [bad exit code] (normal,hpc,optasm)

Note: See TracTickets for help on using tickets.