Is this a concurrency bug in base?

[Jean-Marie Gaillourdet]

Hi Daniel,



On 09.10.2011, at 16:24, Daniel Fischer wrote:

> On Sunday 09 October 2011, 15:30:20, Jean-Marie Gaillourdet wrote:
>> Hi Daniel,
>> 
>> On 09.10.2011, at 14:45, Daniel Fischer wrote:
>>> On Sunday 09 October 2011, 13:52:47, Jean-Marie Gaillourdet wrote:
>>>> This seems to be a Heisenbug as it is extremely fragile, when adding
>>>> a "| grep 1" to the while loop it seems to disappears. At least on
>>>> my computers.
>>> 
>>> Still produces 1s here with a grep.
>> 
>> Well, it may have been bad luck on my site.
> 
> Or maybe Macs behave differently.
> 
>> 
>> Thanks, for reproducing it. I failed to see it on Linux so far. So I
>> guess a bug report is in order?
> 
> I'd think so.  Although due to the changes in 7.2 there's nothing to fix 
> here anymore, it might point to something still to be fixed.
> 
>> Or are bug reports to old versions not welcome?
> 
> Within reason. Reporting bugs against 5.* would be rather pointless now, 
> but >= 6.10 should be okay.
> If the behaviour has been fixed as a by-product of some other change, at 
> least a test could be made to prevent regression.
> If, like here, the directly concerned code has been changed, probably 
> nothing is to be done, but the bug may have been caused by something else 
> which still needs to be fixed, so better report one bug too many.


I've been chasing the source of the non-deterministic of my library for quite some time now. And at several points in time I had the impression that modifyMVar would not always be atomic. (Of course under the assumption that no other code touches the MVar). But in that case as well as in the case here it is only reproducible by looping the execution of the binary. Moving the loop into the Haskell program will show the bug in the first iteration or never.   

I will report a bug.

Jean