#7299 closed bug (fixed)

threadDelay broken in ghci, Mac OS X

Reported by: tmcdonell Owned by: igloo
Priority: highest Milestone: 7.6.2
Component: GHCi Version: 7.6.1
Keywords: Cc: chak@…, erkokl@…
Operating System: MacOS X Architecture: Unknown/Multiple
Type of failure: GHCi crash Difficulty: Unknown
Test Case: Blocked By:
Blocking: Related Tickets:

Description

Control.Concurrent.threadDelay fails in ghci on Mac OS X. Behaviour is correct in compiled code. To reproduce, it is enough to just execute threadDelay at the prompt.

Depending on the architecture, I get different behaviour:

  • i386: 7.6.1 and 7.7.20121003: segmentation fault (11)
  • x86_64: 7.6.1 and 7.7.20121003: executes without segfault, but there is no actual delay.

This is on Mac OS X 10.7.5 and 10.8.2.

Correct behaviour for ghci-7.6.1-x86_64 on Ubuntu 12.04. Also fine on Mac in the 7.4 series.

Example output:

Nightfall $ ghci
GHCi, version 7.6.1: http://www.haskell.org/ghc/  :? for help
Loading package ghc-prim ... linking ... done.
Loading package integer-gmp ... linking ... done.
Loading package base ... linking ... done.

Prelude > Foreign.Storable.sizeOf (undefined :: Int)
4

Prelude > Control.Concurrent.threadDelay (1000 * 1000)
Segmentation fault: 11

Sample program for the second case:

import Control.Concurrent

count :: Int -> IO ()
count n
  | n <= 0      = return ()
  | otherwise   = do
      putStrLn $ shows n "-ah-ha-ha"
      threadDelay (1000 * 1000) -- 1 second
      count (n-1)

main :: IO ()
main = count 10

Change History (13)

comment:1 Changed 19 months ago by simonmar

  • Difficulty set to Unknown
  • Milestone set to 7.6.2
  • Priority changed from normal to highest

Looks serious, thanks for the report.

comment:2 Changed 18 months ago by chak

  • Cc chak@… added

comment:3 follow-up: Changed 17 months ago by joeyadams

What happens if you compile with -threaded ? ghci uses the threaded RTS. Compiling with ghc, by default, does not use the threaded RTS. threadDelay follows a much different code path with -threaded than without.

comment:4 Changed 17 months ago by igloo

  • Owner set to igloo

comment:5 in reply to: ↑ 3 Changed 17 months ago by tmcdonell

Replying to joeyadams:

What happens if you compile with -threaded ? ghci uses the threaded RTS. Compiling with ghc, by default, does not use the threaded RTS. threadDelay follows a much different code path with -threaded than without.

Works fine compiled with "ghc -threaded", both i386 and x86_64 on 7.6.1.

comment:6 Changed 17 months ago by igloo

  • Blocked By 3658 added

I can reproduce this.

However, it doesn't happen with a dynamic-by-default build.

comment:7 Changed 17 months ago by simonpj

We don't know what is wrong but Ian speculates that it's a bug in the GHCi linker, since it works with dynamic-by-default. It could also be something to do with the fact that with the GHCi linker we get two copies of the base package but have to do some hacks to make sure that there is only one blob of I/O manager state.

Has anyone else come across this threadDelay problem in MacOSX? Can anyone help?

Simon

comment:8 Changed 15 months ago by lerkok

  • Cc erkokl@… added

I can reproduce this on Snow Leopard with GHC 7.6.1.

comment:9 Changed 15 months ago by igloo

Looks like this is related to us having 2 copies of the base library around.

The crash happens sometime around a call to absolute_time in libraries/base/cbits/DarwinUtils.c. This file doesn't exist in 7.4, which explains why it worked then.

comment:10 Changed 15 months ago by thorkilnaur

I should mention that I am working on identifying the patch(es) that introduced this problem. The problem is reproducible on my Intel Mac OS X 10.5 (the tn23 builder), sometimes as segmentation faults, but more often as no apparent wait when threadDelay is called via ghci.

I am using the tn23 builds as "synchronization points". Using the "repo versions" reported for each build, I have been able to, with some adjustments, to reproduce successful builds and, not least, avoid unsuccessful ones. So far, I have been able to narrow the problem as being introduced between tn23 build 599 (http://darcs.haskell.org/ghcBuilder/builders/tn23/599.html) and build 600 (http://darcs.haskell.org/ghcBuilder/builders/tn23/600.html). (Build 599 is a failed build, but it is possible to repair by applying the changes of patch "da102b36bfee605d4849ab74908886b5270d37ad Fix RTS build on OS X" by hand.) In other words, the adjusted build 599 succeeds and threadDelay seems to work. And build 600 succeeds and threadDelay provides no apparent delay.

It is slow going, but I expect to be able to narrow down further within the next couple of days. In the meantime, the present interval may provide some useful hints.

Best regards
Thorkil

comment:11 Changed 15 months ago by simonmar

The state in libraries/base/cbits/DarwinUtils.c would explain why threadDelay would return immediately in GHCi, but I don't see anything that would cause it to crash.

In any case, the fix is to move initialize_timer and scaling_factor into the RTS (or maybe just use the existing RTS facilities).

comment:12 Changed 15 months ago by igloo

  • Blocked By 3658 removed

comment:13 Changed 15 months ago by igloo

  • Resolution set to fixed
  • Status changed from new to closed

Fixed by

commit 8a3399d5169af7a82c2c13ca7184fd307f6ea3d8
Author: Ian Lynagh <ian@well-typed.com>
Date:   Wed Jan 16 16:35:44 2013 +0000

    Use the RTS getMonotonicTime to implement getMonotonicNSec; fixes #7299
    
    I'm not entirely sure where the segfault was coming from, but it was
    almost certainly related to there being 2 copies of the base package
    around, and the interpreted one not having its timer code initialised.
Note: See TracTickets for help on using tickets.