Probably not. The code includes things like waiting on condition variables and expecting to be resumed by other threads.
On Wed, May 4, 2011 at 2:13 PM, Walter Bright <[email protected]>wrote: > 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 <[email protected]>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 >> [email protected] >> http://lists.puremagic.com/mailman/listinfo/phobos >> > > > _______________________________________________ > phobos mailing > [email protected]http://lists.puremagic.com/mailman/listinfo/phobos > > > _______________________________________________ > phobos mailing list > [email protected] > http://lists.puremagic.com/mailman/listinfo/phobos >
_______________________________________________ phobos mailing list [email protected] http://lists.puremagic.com/mailman/listinfo/phobos
