I guess I'm asking if there is a way to execute all those paths in a single
threaded manner, in order to flush out any suspected code gen bugs.
On 5/4/2011 10:39 AM, David Simcha wrote:
Yes, it works as a single threaded program, but there are a lot of code paths
that are never taken unless a worker thread finishes a job before the
submitter thread needs the result (which obviously can't happen in
single-threaded mode). Therefore, this does not prove that the issue is a
concurrency bug.
On Wed, May 4, 2011 at 1:37 PM, Walter Bright <wal...@digitalmars.com
<mailto:wal...@digitalmars.com>> wrote:
Does it work as a single threaded program?
On 5/4/2011 6:51 AM, David Simcha wrote:
I went a slightly different route and tried to reduce the problem to
as small a test case as possible, like I would normally do for a
compiler bug. So far I've managed to reduce it to ~560 lines. I've
discovered this one's more unstable (i.e. the results change a lot
more in response to slight perturbations) than I thought. Just
changing the layout of the Task struct (deleting member variables that
are no longer used anywhere) makes it go from unit test failures to
access violations. Adding or removing try/catch blocks or empty
destructors in some places can completely prevent the bug from
manifesting. On Linux, if I perturb things slightly by changing the
layout of Task, I get exceptions thrown from core.sync.
This looks like some kind of memory/stack corruption bug but due to
its nondeterminism (only a few thread interleavings seem to take the
proper codepath and I'm not sure which ones) and its very indirect
manifestation (memory corruption; the low order bit overwriting thing
was, I think, just a manifestation of a deeper problem), I am somewhat
at a loss for how to debug it. I've scrutinized the concurrency
related aspects and still can't find any bugs there. However, I can't
prove it's not a concurrency bug since running in single threaded mode
prevents certain code paths from being taken. Unless I get some
advice that changes things, I think my next move is to compare the
disassemblies for cases that work to those for cases that don't.
_______________________________________________
phobos mailing list
phobos@puremagic.com <mailto:phobos@puremagic.com>
http://lists.puremagic.com/mailman/listinfo/phobos
_______________________________________________
phobos mailing list
phobos@puremagic.com
http://lists.puremagic.com/mailman/listinfo/phobos
_______________________________________________
phobos mailing list
phobos@puremagic.com
http://lists.puremagic.com/mailman/listinfo/phobos
