Opened 10 years ago

Closed 8 years ago

#4018 closed bug (fixed)

Concurrency space leak

Reported by: simonpj Owned by:
Priority: high Milestone: 7.4.1
Component: Compiler Version: 6.12.2
Keywords: Cc:
Operating System: Unknown/Multiple Architecture: Unknown/Multiple
Type of failure: Runtime performance bug Test Case: perf/space_leaks/T4018
Blocked By: Blocking:
Related Tickets: Differential Rev(s):
Wiki Page:


This thread describes a space leak that concerns the knot-tying behaviour of the forever combinator.

However, my gut feel is that the leakiness or otherwise should not depend on how forever is defined, so I'm making a ticket to remind me to get back to it. A good place in the thread to start is here


Change History (6)

comment:1 Changed 10 years ago by simonmar

This rang a bell when I saw it - it smells a lot like #2762

EDIT: apologies for the mixed metaphor...

comment:2 Changed 9 years ago by igloo


comment:3 Changed 9 years ago by igloo


comment:4 Changed 8 years ago by igloo


comment:5 Changed 8 years ago by simonmar

difficulty: Unknown
Priority: normalhigh
Type of failure: None/UnknownRuntime performance bug

This seems to be fixed since 7.0. I presume it is arity analysis allowing the definition of forever to be eta-expanded. For reference here is the code, compile with 6.12.x and -O -fno-state-hack to illustrate the leak:

module Main (main) where

import Control.Concurrent
always :: Monad m => m a -> m b
always a = a >> always a
always :: Monad m => m a -> m b
always a = do
    _ <- a
    always a

spawner :: IO ()
spawner = always $ do
    forkIO $ always (return ())
    putStrLn "Delaying"
    threadDelay 1000000

main :: IO ()
main = do
    putStrLn "Spawning"
    forkIO spawner
    putStrLn "Delaying main"
    threadDelay 4000000

We should add this as a test and close.

comment:6 Changed 8 years ago by simonmar

Resolution: fixed
Status: newclosed
Test Case: perf/space_leaks/T4018
Note: See TracTickets for help on using tickets.