[phobos] State of std.parallelism unit tests

[David Simcha]

Thanks.  A second look with fresher eyes revealed a subtle but serious 
bug in the ResubmittingTasks base mixin (which affects parallel foreach, 
map and amap) and a relatively minor corner-case bug in reduce().  Both 
were introduced after the 2.053 release as a result of over-aggressive 
optimizations.  I've checked in fixes for these.  I'm not sure whether 
they're the root cause of the issues you're seeing, though.  If it's not 
too much work, please try to reproduce your bugs again.

On 6/2/2011 3:10 AM, Jonathan M Davis wrote:
> On 2011-05-28 18:41, David Simcha wrote:
>> Thanks for letting me know.  I have no idea why this is happening.  I was
>> seeing some weirdness on FreeBSD only, but I gave up trying to solve that
>> until the FreeBSD port is more stable or I can reproduce it on some other
>> OS.  I've run the unittests for std.parallelism on my (old) Athlon 64 X2
>> tens of thousands of times on Linux 64 without any issues, so unfortunately
>> this is going to be hard to debug.  Two questions:
>>
>> 1.  Does it happen on the latest Git version or on the 2.053 release
>> version?
>>
>> 2.  Could you try to figure out which test is failing?
> I added statements at the beginning and end of each unit test block, and when
> it segfaults, I get this:
>
> std/parallelism.d(223)
> std/parallelism.d(236)
> std/parallelism.d(3155)
> totalCPUs = 6
> std/parallelism.d(3378)
>
> So, that's the unit testblock that starts with
>
>      poolInstance = new TaskPool(2);
>      scope(exit) poolInstance.stop();
>
> 3378 is the line at the end of that unittest block, so I assume that there's
> either a destructor that's causing the problem or that poolInstance.stop() is
> causing the problem. Also, if it matters, it was running the unit tests in
> release mode when it died. However, I _have_ seen that test freeze while in
> debug mode (though it's quite possible that the program freezing and the
> segfault are completely separate). Also, the freeze definitely happens
> sometimes with 2.053, but I don't know if the segfault does. It happens
> infrequently enough that it's hard to tell. I expect that it does, but I
> haven't seen it yet. However, running dmd 2.053 (with the latest druntime and
> Phobos), I did get this test failure once:
>
> core.exception.AssertError at std/parallelism.d(3244): [2, 4, 5, 6]
>
> (which is probably 3241 if you don't have the extra print statements that I
> added at the beginning and end of the unittest blocks). But again,
> std.parallelism _usually_ succeeds, so it's kind of hard to know what's going
> on with the tests. I've seen them freeze after printing out totalCPUs = 6 (and
> before it gets to the end of that unittest block). I've seen it segfault. And
> I've seen that AssertError. So, it definitely has intermitent problems on my
> 64-bit, 6-core AMD system with a pure 64-bit stack. How much that has to do
> with my system or the architecture, I have no idea, but _something_ in
> std.parallelism still needs to be ironed out.
>
> - Jonathan M Davis
> _______________________________________________
> phobos mailing list
> phobos at puremagic.com
> http://lists.puremagic.com/mailman/listinfo/phobos
>