[phobos] std.parallelism's unit tests randomly hang on win32

[David Simcha]

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 <walter at digitalmars.com>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 <walter at 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 at puremagic.com
>> http://lists.puremagic.com/mailman/listinfo/phobos
>>
>
>
> _______________________________________________
> phobos mailing listphobos at puremagic.comhttp://lists.puremagic.com/mailman/listinfo/phobos
>
>
> _______________________________________________
> phobos mailing list
> phobos at puremagic.com
> http://lists.puremagic.com/mailman/listinfo/phobos
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/phobos/attachments/20110504/b85e7bcd/attachment.html>