<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
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.<br>
<br>
On 5/4/2011 10:39 AM, David Simcha wrote:
<blockquote
cite="mid:BANLkTi=DysyW666e=1d7JB-y7RueiYFV-A@mail.gmail.com"
type="cite">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.<br>
<br>
<div class="gmail_quote">On Wed, May 4, 2011 at 1:37 PM, Walter
Bright <span dir="ltr"><<a moz-do-not-send="true"
href="mailto:walter@digitalmars.com">walter@digitalmars.com</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt
0.8ex; border-left: 1px solid rgb(204, 204, 204);
padding-left: 1ex;">
Does it work as a single threaded program?
<div class="im"><br>
<br>
On 5/4/2011 6:51 AM, David Simcha wrote:<br>
<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt
0.8ex; border-left: 1px solid rgb(204, 204, 204);
padding-left: 1ex;">
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.<br>
<br>
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.<br>
<br>
</blockquote>
</div>
<div>
<div class="h5">
_______________________________________________<br>
phobos mailing list<br>
<a moz-do-not-send="true"
href="mailto:phobos@puremagic.com" target="_blank">phobos@puremagic.com</a><br>
<a moz-do-not-send="true"
href="http://lists.puremagic.com/mailman/listinfo/phobos"
target="_blank">http://lists.puremagic.com/mailman/listinfo/phobos</a><br>
</div>
</div>
</blockquote>
</div>
<br>
<pre wrap="">
<fieldset class="mimeAttachmentHeader"></fieldset>
_______________________________________________
phobos mailing list
<a class="moz-txt-link-abbreviated" href="mailto:phobos@puremagic.com">phobos@puremagic.com</a>
<a class="moz-txt-link-freetext" href="http://lists.puremagic.com/mailman/listinfo/phobos">http://lists.puremagic.com/mailman/listinfo/phobos</a></pre>
</blockquote>
</body>
</html>