<html>
    <head>
      <base href="https://llvm.org/bugs/" />
    </head>
    <body><table border="1" cellspacing="0" cellpadding="8">
        <tr>
          <th>Bug ID</th>
          <td><a class="bz_bug_link 
          bz_status_NEW "
   title="NEW --- - race in process return code collection in python test runner"
   href="https://llvm.org/bugs/show_bug.cgi?id=25019">25019</a>
          </td>
        </tr>

        <tr>
          <th>Summary</th>
          <td>race in process return code collection in python test runner
          </td>
        </tr>

        <tr>
          <th>Product</th>
          <td>lldb
          </td>
        </tr>

        <tr>
          <th>Version</th>
          <td>unspecified
          </td>
        </tr>

        <tr>
          <th>Hardware</th>
          <td>PC
          </td>
        </tr>

        <tr>
          <th>OS</th>
          <td>All
          </td>
        </tr>

        <tr>
          <th>Status</th>
          <td>NEW
          </td>
        </tr>

        <tr>
          <th>Severity</th>
          <td>normal
          </td>
        </tr>

        <tr>
          <th>Priority</th>
          <td>P
          </td>
        </tr>

        <tr>
          <th>Component</th>
          <td>All Bugs
          </td>
        </tr>

        <tr>
          <th>Assignee</th>
          <td>lldb-dev@lists.llvm.org
          </td>
        </tr>

        <tr>
          <th>Reporter</th>
          <td>todd.fiala@gmail.com
          </td>
        </tr>

        <tr>
          <th>CC</th>
          <td>llvm-bugs@lists.llvm.org
          </td>
        </tr>

        <tr>
          <th>Classification</th>
          <td>Unclassified
          </td>
        </tr></table>
      <p>
        <div>
        <pre>I have noticed that roughly 1 in 5 times, one of the process control child
process return code tests is failing.  It is receiving a 0 return code from the
process that was definitely returning a 10 value (verified in multiple ways).

This looks like it maybe similar to what was posted here:
<a href="http://stackoverflow.com/questions/31539749/python-subprocess-read-returncode-is-sometimes-different-from-returned-code">http://stackoverflow.com/questions/31539749/python-subprocess-read-returncode-is-sometimes-different-from-returned-code</a>

It looks like the root of it is that subprocess.Popen.communicate() indirectly
sets the return code, and wait() does as well.  And the mechanism by which this
happens is not thread safe.

Since this code is happening in two different threads of execution
(intentionally), this is going to be problematic.

I had initially torn out the communicate() call and replaced it with an
asyncore loop, which we can easily work in our own poll() check to manage
lifetime of the process.  There's a simple state flow that needs to happen
here.

I yanked that out since we didn't have the asyncore.file_dispatcher on the
Windows side.

I think we may need a simple stdout/stderr pipe pump that essentially does what
asyncore did, in a pure-python manner, so that we can make sure poll() happens
in a thread-safe manner.</pre>
        </div>
      </p>
      <hr>
      <span>You are receiving this mail because:</span>
      
      <ul>
          <li>You are the assignee for the bug.</li>
      </ul>
    </body>
</html>