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