#7270: Incorrect optimization with Data.ByteString.append
------------------------------------------+---------------------------------
Reporter: ocheron | Owner: duncan
Type: bug | Status: closed
Priority: highest | Milestone: 7.6.2
Component: libraries (other) | Version: 7.6.1
Resolution: fixed | Keywords:
Os: Unknown/Multiple | Architecture: Unknown/Multiple
Failure: Incorrect result at runtime | Difficulty: Unknown
Testcase: | Blockedby:
Blocking: | Related:
------------------------------------------+---------------------------------
Changes (by duncan):
* status: new => closed
* resolution: => fixed
Comment:
Committed to the upstream bytestring repo. So it'll be fixed in the next
bytestring point release.
{{{
Tue Sep 25 16:21:14 BST 2012 Duncan Coutts <dun...@community.haskell.org>
* Fix a few incorrect uses of inlinePerformIO
The incorrect use of inlinePerformIO resulted in multiple calls to
mallocByteString being shared, and hence two different strings sharing
the same memory. See http://hackage.haskell.org/trac/ghc/ticket/7270
Consider:
foo x = s `seq` r
where
r = B.map succ x
s = B.map succ r
The B.map function used a pattern like:
map f (PS fp s len) = inlinePerformIO $ ...
fp' <- mallocByteString len
Now, in the foo function above, we have both r and s where the compiler
can see that the 'len' is the same in both cases, and with
inlinePerformIO exposing everything, the compiler is free to share the
two calls to mallocByteString len.
The answer is not to use inlinePerformIO if we are allocating, but to
use
unsafeDupablePerformIO instead. Another reminder that inlinePerformIO is
really really unsafe, and that we should be using the ST monad instead.
}}}
--
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/7270#comment:4>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
_______________________________________________
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
