[GHC] #14356: "Main: thread blocked indefinitely in an MVar operation" in fixIO
#14356: "Main: thread blocked indefinitely in an MVar operation" in fixIO -------------------------------------+------------------------------------- Reporter: nickkuk | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Runtime | Version: 8.2.1 System | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Incorrect result Unknown/Multiple | at runtime Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- I'm not sure whether such behavior is expected, but this program {{{ import System.IO main = fixIO (\x -> return 1) >>= print }}} prints "1"; and this {{{ import System.IO main = fixIO (\(x, _) -> return (1, print x)) >>= print . fst }}} prints "Main: thread blocked indefinitely in an MVar operation". Second program arises from something like {{{ {-# LANUGAGE RecursiveDo #-} main = mdo ... x <- return 1 let f = do ... print x ... ... return f }}} It is not necessary to call f somewhere in mdo to get "Main: thread blocked indefinitely in an MVar operation". -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14356> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler
#14356: "Main: thread blocked indefinitely in an MVar operation" in fixIO -------------------------------------+------------------------------------- Reporter: nickkuk | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 8.2.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by nickkuk): I tried to test my example with David's fixIO (#13613), but couldn't got it compiled, because I'm not familiar with these ghc internals. Does #13613 solves the problem in this ticket? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14356#comment:1> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler
#14356: "Main: thread blocked indefinitely in an MVar operation" in fixIO -------------------------------------+------------------------------------- Reporter: nickkuk | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 8.2.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by nickkuk): * cc: dfeuer (added) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14356#comment:2> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler
#14356: "Main: thread blocked indefinitely in an MVar operation" in fixIO -------------------------------------+------------------------------------- Reporter: nickkuk | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 8.2.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Old description:
I'm not sure whether such behavior is expected, but this program {{{ import System.IO
main = fixIO (\x -> return 1) >>= print }}} prints "1"; and this {{{ import System.IO
main = fixIO (\(x, _) -> return (1, print x)) >>= print . fst }}} prints "Main: thread blocked indefinitely in an MVar operation".
Second program arises from something like {{{ {-# LANUGAGE RecursiveDo #-}
main = mdo ... x <- return 1 let f = do ... print x ... ... return f }}} It is not necessary to call f somewhere in mdo to get "Main: thread blocked indefinitely in an MVar operation".
New description: I'm not sure whether such behavior is expected, but this program {{{#!hs import System.IO main = fixIO (\x -> return 1) >>= print }}} prints "1"; and this {{{#!hs import System.IO main = fixIO (\(x, _) -> return (1, print x)) >>= print . fst }}} prints "Main: thread blocked indefinitely in an MVar operation". Second program arises from something like {{{#!hs {-# LANUGAGE RecursiveDo #-} main = mdo ... x <- return 1 let f = do ... print x ... ... return f }}} It is not necessary to call f somewhere in mdo to get "Main: thread blocked indefinitely in an MVar operation". -- Comment (by bgamari): David, could you look at this? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14356#comment:3> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler
#14356: "Main: thread blocked indefinitely in an MVar operation" in fixIO -------------------------------------+------------------------------------- Reporter: nickkuk | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 8.2.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by alexbiehl): By using a lazy pattern match it is working again: {{{ main = fixIO (\ ~(x, _) -> return (1, print x)) >>= print . fst }}} Looking at the core for the reported version we find: (compiled with -O2 to better understand the flow) {{{#!haskell main1 = \ s_a1AP -> case newMVar# s_a1AP of { (# ipv_a1AZ, ipv1_a1B0 #) -> case ((unsafeDupableInterleaveIO ((\ eta_a1B8 -> readMVar# ipv1_a1B0 eta_a1B8) `cast` <Co:6>)) `cast` <Co:5>) ipv_a1AZ of { (# ipv2_X1B5, ipv3_X1B7 #) -> -- ipv3_X1B7 is our chunk which delays the readMVar# -- entering ipv3_X1B7 causes a deadlock! case ipv3_X1B7 of { (x_aV8, ds2_d1zX) -> case putMVar# ipv1_a1B0 (main3, (hPutStr2 stdout ($fShowInteger_$cshow x_aV8) True) `cast` <Co:3>) ipv2_X1B5 of s2#_a25J { __DEFAULT -> hPutStr2 stdout main2 True s2#_a25J } } } } }}} By using a strict pattern match on the tuple we trigger the `readMVar#` which blocks and deadlocks as we can't make further progress. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14356#comment:4> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler
#14356: "Main: thread blocked indefinitely in an MVar operation" in fixIO -------------------------------------+------------------------------------- Reporter: nickkuk | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 8.2.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by dfeuer): Yes, I'll look at this happily. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14356#comment:5> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler
#14356: "Main: thread blocked indefinitely in an MVar operation" in fixIO -------------------------------------+------------------------------------- Reporter: nickkuk | Owner: (none) Type: bug | Status: new Priority: low | Milestone: Component: Runtime System | Version: 8.2.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Poor/confusing | Unknown/Multiple error message | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by dfeuer): * priority: normal => low * failure: Incorrect result at runtime => Poor/confusing error message Comment: nickkuk, as alexbiehl sort of suggests, this is the expected behavior for the second example, although I think it would be worth trying to improve the error message. Unfortunately, your `mdo` example was stripped down too far to be able to interpret. Do you think you can provide a proper reproduction of what you see as bad `mdo` desugaring? I'll mark this low priority for the error message improvement; if you find a real desugaring problem we'll bump it back up. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14356#comment:6> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler
#14356: "Main: thread blocked indefinitely in an MVar operation" in fixIO -------------------------------------+------------------------------------- Reporter: nickkuk | Owner: (none) Type: bug | Status: new Priority: low | Milestone: Component: Runtime System | Version: 8.2.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Poor/confusing | Unknown/Multiple error message | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Old description:
I'm not sure whether such behavior is expected, but this program {{{#!hs import System.IO
main = fixIO (\x -> return 1) >>= print }}} prints "1"; and this {{{#!hs import System.IO
main = fixIO (\(x, _) -> return (1, print x)) >>= print . fst }}} prints "Main: thread blocked indefinitely in an MVar operation".
Second program arises from something like {{{#!hs {-# LANUGAGE RecursiveDo #-}
main = mdo ... x <- return 1 let f = do ... print x ... ... return f }}} It is not necessary to call f somewhere in mdo to get "Main: thread blocked indefinitely in an MVar operation".
New description: I'm not sure whether such behavior is expected, but this program {{{#!hs import System.IO main = fixIO (\x -> return 1) >>= print }}} prints "1"; and this {{{#!hs import System.IO main = fixIO (\(x, _) -> return (1, print x)) >>= print . fst }}} prints "Main: thread blocked indefinitely in an MVar operation". -- Comment (by nickkuk): alexbiehl, thanks a lot! I understand this stuff better now. David, sorry! I believe that you are right - I can't produce example with mdo that behaves like my second program. Desugarer (that builded in my brain :) did mistake when I consider this more easier program: {{{#!hs {-# LANGUAGE RecursiveDo #-} main = mdo print x x <- return 1 return () }}} (btw, it throws "Main: thread blocked indefinitely in an MVar operation" too). I will delete last part of ticket with mdo to decrease confusing. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14356#comment:7> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler
#14356: "Main: thread blocked indefinitely in an MVar operation" in fixIO -------------------------------------+------------------------------------- Reporter: nickkuk | Owner: (none) Type: bug | Status: new Priority: low | Milestone: Component: Runtime System | Version: 8.2.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Poor/confusing | Unknown/Multiple error message | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Description changed by nickkuk: Old description:
I'm not sure whether such behavior is expected, but this program {{{#!hs import System.IO
main = fixIO (\x -> return 1) >>= print }}} prints "1"; and this {{{#!hs import System.IO
main = fixIO (\(x, _) -> return (1, print x)) >>= print . fst }}} prints "Main: thread blocked indefinitely in an MVar operation".
New description: I'm not sure whether such behavior is expected, but this program {{{#!hs import System.IO main = fixIO (\x -> return 1) >>= print }}} prints "1"; and this {{{#!hs import System.IO main = fixIO (\(x, _) -> return (1, print x)) >>= print . fst }}} prints "Main: thread blocked indefinitely in an MVar operation". This behavior can be fixed with additional ~ as alexbiehl said below. Also, this program with mdo {{{#!hs {-# LANGUAGE RecursiveDo #-} main = mdo print x x <- return 1 return () }}} prints "Main: thread blocked indefinitely in an MVar operation". -- -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14356#comment:8> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler
#14356: "Main: thread blocked indefinitely in an MVar operation" in fixIO -------------------------------------+------------------------------------- Reporter: nickkuk | Owner: (none) Type: bug | Status: patch Priority: low | Milestone: Component: Runtime System | Version: 8.2.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Poor/confusing | Unknown/Multiple error message | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4113 Wiki Page: | -------------------------------------+------------------------------------- Changes (by dfeuer): * status: new => patch * differential: => Phab:D4113 Comment: I've put up a differential to improve the error message. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14356#comment:9> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler
#14356: "Main: thread blocked indefinitely in an MVar operation" in fixIO -------------------------------------+------------------------------------- Reporter: nickkuk | Owner: (none) Type: bug | Status: patch Priority: low | Milestone: Component: Runtime System | Version: 8.2.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Poor/confusing | Unknown/Multiple error message | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4113 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari <ben@…>): In [changeset:"b938576d151731b85314987fc550c17cfe824178/ghc" b938576/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="b938576d151731b85314987fc550c17cfe824178" Add custom exception for fixIO Traditionally, `fixIO f` throws `BlockedIndefinitelyOnMVar` if `f` is strict. This is not particularly friendly, since the `MVar` in question is just part of the way `fixIO` happens to be implemented. Instead, throw a new `FixIOException` with a better explanation of the problem. Reviewers: austin, hvr, bgamari Subscribers: rwbarton, thomie GHC Trac Issues: #14356 Differential Revision: https://phabricator.haskell.org/D4113 }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14356#comment:10> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler
#14356: "Main: thread blocked indefinitely in an MVar operation" in fixIO -------------------------------------+------------------------------------- Reporter: nickkuk | Owner: (none) Type: bug | Status: closed Priority: low | Milestone: 8.4.1 Component: Runtime System | Version: 8.2.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Poor/confusing | Unknown/Multiple error message | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4113 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: patch => closed * resolution: => fixed * milestone: => 8.4.1 -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14356#comment:11> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler
#14356: "Main: thread blocked indefinitely in an MVar operation" in fixIO -------------------------------------+------------------------------------- Reporter: nickkuk | Owner: (none) Type: bug | Status: closed Priority: low | Milestone: 8.4.1 Component: Runtime System | Version: 8.2.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Poor/confusing | Unknown/Multiple error message | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4113 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ryan Scott <ryan.gl.scott@…>): In [changeset:"ce27c7d5fe3c335dcc354b70fdfc17831a6848f6/ghc" ce27c7d/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="ce27c7d5fe3c335dcc354b70fdfc17831a6848f6" Correct FixIOException's @since annotation retroactively Summary: In D4113, a `FixIOException` data type was added with a `@since TODO` annotation, but it seems that `TODO` made it out into `base-4.11` itself. I've (retroactively) fixed this and added an entry to the `base-4.11` entry in the `changelog`. Test Plan: Read it Reviewers: dfeuer, hvr, bgamari Reviewed By: dfeuer Subscribers: thomie, carter GHC Trac Issues: #14356, #15025 Differential Revision: https://phabricator.haskell.org/D4578 }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14356#comment:12> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler
participants (1)
-
GHC