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@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
[email protected]
http://lists.puremagic.com/mailman/listinfo/phobos
_______________________________________________
phobos mailing list
[email protected]
http://lists.puremagic.com/mailman/listinfo/phobos
