Boxed mutable vector is buggy in doctests

[lehins]

Since I've added some doctests for grow function we've been experiencing some occasional segfaults on CI, but it was hard to spot where exactly the problem is lurking, since examples themselves seem to be correct and problem can't be replicated outside of doctests. I've experienced very similar problem elsewhere with boxed MutableArray# and SmallMutableArray#, so I had a hunch (#382 (comment)) that it had to do with boxed arrays and today we got this error on CI:

src/Data/Vector/Mutable.hs:368: failure in expression `V.unsafeFreeze mv''
expected: [10,20,888,999,777]
 but got: [10,20,283563033355,999,777]
                 ^

Examples: 339  Tried: 338  Errors: 0  Failures: 1

See https://github.com/haskell/vector/runs/2461343762?check_suite_focus=true

I'll inline example from haddock for the record:

-- >>> import qualified Data.Vector as V
-- >>> import qualified Data.Vector.Mutable as MV
-- >>> mv <- V.thaw $ V.fromList ([10, 20, 30] :: [Integer])
-- >>> mv' <- MV.grow mv 2
--
-- The two extra elements at the end of the newly allocated vector will be
-- uninitialized and will result in an error if evaluated, so me must overwrite
-- them with new values first:
--
-- >>> MV.write mv' 3 999
-- >>> MV.write mv' 4 777
-- >>> V.unsafeFreeze mv'
-- [10,20,30,999,777]
--
-- It is important to note that the source mutable vector is not affected when
-- the newly allocated one is mutated.
--
-- >>> MV.write mv' 2 888
-- >>> V.unsafeFreeze mv'
-- [10,20,888,999,777]
-- >>> V.unsafeFreeze mv
-- [10,20,30]

It is clear that there is something really weird going on. I am not 100% sure where the problem is really coming from, although I do suspect it probably is doctests, but since it originated here I'd like to have it as a starting point.

@Shimuuar You've expressed interest in investigating it. Any ideas?

[andrewthad]

This doctest is bad. It calls unsafeFreeze on the same mutable vector twice, which is explicitly undefined behavior.

[lehins]

@andrewthad You know, I thought exact same thing a moment ago and did just that in 997615a

However, this is not described anywhere in a good detail. The only place I saw any mention of this was in primitive: "The array should not be modified after the conversion.", which doesn't tell us the reason why it should not be modified. The primop itself doesn't talk about this at all.

I know you are more familiar with the actual primops, so I have few questions for you:

• how come this is not a problem for MutableByteArray#, just the boxed arrays?
• why mutable array cannot be mutated? Is there some flag that is flipped when unsafeFreeze is called on it which somehow affects GC?
• how come I cannot reproduce it with compiled code or in ghci, just in doctests?
• would this be a legit fix (not that this would be put into documentation, just curious):

>>> mv <- V.thaw $ V.fromList ([10, 20, 30] :: [Integer])
>>> mv' <- MV.grow mv 2
>>> MV.write mv' 3 999
>>> MV.write mv' 4 777
>>> v' <- V.unsafeFreeze mv'
>>> print v'
[10,20,30,999,777]
>>> mv'' <- V.unsafeThaw v'
>>> MV.write mv'' 2 888
>>> v''' <- V.unsafeFreeze mv''
>>> print v'''
[10,20,888,999,777]
>>> V.unsafeFreeze mv
[10,20,30]

[andrewthad]

Here's the reason I'm certain of for why mutating after performing an in-place freeze is bad. For any type of array (Array# or ByteArray#), let's say that you do this:

foo :: Char
foo = runST $ do
  dst <- new 3 -- starts out uninitialized
  write dst 0 'a'
  write dst 1 'b'
  write dst 2 'c'
  arr <- unsafeFreeze dst
  let x = index arr 1
  write dst 1 'd'
  pure x

What is the value of foo? Should it be 'd' or 'b'. It depends on the optimizations that GHC applies. I've not testing this case specifically, but at -O0 and at -O2, GHC might produce programs with different behaviors. (It should be possible for this to happen with either primitive or vector.) This is because one of GHC's core-to-core involving sinking let bindings, that is, floating them inward toward the place whether they are actually used. Another pass does the opposite, hoisting them upward, which could also change the behavior of a program that fails to respect the no-use-after-freeze invariant, but the floating inward pass is the one that matter more in this example. Essentially, the program could become:

foo :: Char
foo = runST $ do
  dst <- new 3 -- starts out uninitialized
  write dst 0 'a'
  write dst 1 'b'
  write dst 2 'c'
  arr <- unsafeFreeze dst
  write dst 1 'd'
  let x = index arr 1
  pure x

I'll write up some more observations later tonight.

[lehins]

Right. The floating out part certainly makes sense, but that is not the problem in the original doctest. There is exact sequencing because the value is printed to stdout, thus it can't be floated out.

[lehins]

Digging through the actual implementation does not reveal the reason to me. unsafeThawArray# and unsafeFreezeArray# thawArray# and freezeArray# are both implemented using the same macro cloneArray: namely create a new array of pointers and copy over all of the addresses with memcpy. The only difference between the two is that the new array is created with a different flag: stg_MUT_ARR_PTRS_DIRTY_info and stg_MUT_ARR_PTRS_FROZEN_CLEAN_info respectfully.

This is not the most efficient way to freeze/thaw arrays, although it is probably necessary for GC, but it should allow for the behavior in the original doctest, because the mutable array that is being frozen is left untouched upon freezing. That would explain why I can't reproduce it outside doctests. My guess is doctests executes those tests in some weird way.

[andrewthad]

unsafeThaw# and unsafeFreeze# do not use memcpy. They just mark the header word since they are in-place operations.

[lehins]

@andrewthad It looks like it does to me:

• https://gitlab.haskell.org/ghc/ghc/-/blob/d2399a46a01a6e46c831c19e797e656a0b8ca16d/includes/Cmm.h#L812
• https://gitlab.haskell.org/ghc/ghc/-/blob/d2399a46a01a6e46c831c19e797e656a0b8ca16d/rts/PrimOps.cmm#L353

[lehins]

Oh damn, you are right, I was looking at freezeArray#!!!

[andrewthad]

Also, fwiw, I consider unsafeThaw# to be a generally bad primop. The only somewhat legitimate use for it that I've ever seen is in unordered-containers, where is used to make in-place modifications to a hashmap that is very carefully used linearly. Typically though, if you know that you are going to have to in-place thaw an array, you shouldn't have frozen it yet. And then since you'll be using write and read (and not index), all operations are guaranteed to be sequenced correctly.

You're looking at stg_freezzeArrayzh and stg_thawArrayzh, which are out-of-line primops. EDIT: Ah, you already figured this out.

[lehins]

Now that I looked into the right primop it all makes total sense. @andrewthad Thank you for your feedback.

Also, fwiw, I consider unsafeThaw# to be a generally bad primop.

100% agree: #139 (comment)

[lehins]

Fix for the bug is in #384