<html>
    <head>
      <base href="http://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 --- - waitpid fails after attach to processes that aren't group leaders"
   href="http://llvm.org/bugs/show_bug.cgi?id=16229">16229</a>
          </td>
        </tr>

        <tr>
          <th>Summary</th>
          <td>waitpid fails after attach to processes that aren't group leaders
          </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>Linux
          </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@cs.uiuc.edu
          </td>
        </tr>

        <tr>
          <th>Reporter</th>
          <td>andrew.kaylor@intel.com
          </td>
        </tr>

        <tr>
          <th>Classification</th>
          <td>Unclassified
          </td>
        </tr></table>
      <p>
        <div>
        <pre>On Linux, when LLDB attaches to a process that is not a group leader the
MonitorChildProcessThread will terminate prematurely.  This happens because the
call to waitpid(-1*pid,...) fails with an ECHILD error.

It is possible to avoid this error by passing just -1 to waitpid, but that
results in signals for all children (including LLDB threads) to be reported. 
More investigation is required to determine the feasibility of this solution.

One situation in which this condition occurs is when the process to which we
are attaching is launched from a Python script using the subprocess.Popen
constructor.  This failure is demonstrated in the
CreateAfterAttach.test_create_after_attach_with_dwarf_and_popen test case.  A
workaround is demonstrated by the
CreateAfterAttach.test_create_after_attach_with_dwarf_and_popen test case. 
Both are in test/functionalities/thread/create_after_attach.</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>