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
_______________________________________________
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Reply via email to