Non-deterministic pure code in Data.Typeable

[guest]

Comparing the result of 'typeOf ()' performed in different threads sometimes yields true and sometimes false. To reproduce compile the attached source file with

ghc-7.0.3 -threaded -rtsopts TypeRepEq?.hs

And execute it in a shell loop. Looping the inside the Haskell program will usually not show the bug.

while true ; do ./TypeReqEq +RTS -N ; done

Every program run will print either "Ok" or "typeOf () /= typeOf ()". The latter would indicate the bug.

The issue has been discussed on the glasgow-haskell-users mailing list in this thread:  http://thread.gmane.org/gmane.comp.lang.haskell.glasgow.user/20754

Different people said that they can reproduce the bug on Mac OS X and Linux with different versions of GHC 6.12.x and 7.0.x. GHC 7.2 does not show the bug.

[guest]

TypeRepEq?.hs

[simonpj]

Thank you for the detailed investigation. I have not followed all the details of this thread, but I think that it may (happily) represent a bug in generating TypeReps that is already fixed.

• We used to have a global cache from which we generated unique Int keys corresponding to type constructors. The trouble with this was that (a) you weren’t guaranteed to get the same key in every run, and (b) the cache was not initially designed to be thread-safe, and I’m not sure that we’d closed all race conditions.

• But NOW we generate a MD5 hash, or fingerprint, of the type. So there is no global cache, no race condition, and you should get the same behaviour ever time.

In short, can you try with 7.2?

Thanks

Simon

[jmg]

I had already tested with 7.2 and the bug did not show up. Nevertheless I started the discussion, because I wanted to make sure that it is not my fault, and because I needed a workaround. Now I have one. Thanks for the confirmation.

[simonmar]

Sorry about the bug. It is fixed in 7.2.1 and later, but we aren't planning to patch older releases. I wish we had noticed this bug earlier!