#7493: STM and TVar report incorrect results
------------------------------------------+---------------------------------
Reporter: parcs | Owner:
Type: bug | Status: new
Priority: highest | Milestone: 7.6.2
Component: Runtime System | Version: 7.6.1
Resolution: | Keywords:
Os: Unknown/Multiple | Architecture: Unknown/Multiple
Failure: Incorrect result at runtime | Difficulty: Unknown
Testcase: | Blockedby:
Blocking: | Related:
------------------------------------------+---------------------------------
Comment(by fryguybob):
I've traced down the point of divergence between a test that works and one
that does not. The following works:
{{{
import Control.Concurrent.STM
main = do
x <- atomically $ do
r <- newTVar 1
writeTVar r 2
writeTVar r 1 `orElse` return ()
readTVar r
print x
}}}
But if we change to:
{{{
import Control.Concurrent.STM
main = do
x <- atomically $ do
let a = 1
r <- newTVar a
writeTVar r 2
writeTVar r a `orElse` return ()
readTVar r
print x
}}}
Then when we try to commit the inner transaction with
`stmCommitNestedTransaction` we enter `validate_and_acquire_ownership` and
hit `entry_is_update`
([https://github.com/ghc/ghc/blob/ghc-7.6/rts/STM.c#L809 code here]) which
returns false (the current value is the exact `a` that initialized in
`newTVar`). In the one that works each `1` is a different thunk
(`Integer`, unlike `Int` I said before; using `Int` it does indeed fail).
I'm still tracking down what happens after this, but now we know the
difference between the examples.
--
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/7493#comment:7>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
_______________________________________________
Glasgow-haskell-bugs mailing list
[email protected]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
