<html>
    <head>
      <base href="https://bugs.llvm.org/">
    </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 - lldb-server can deadlock in ack-mode"
   href="https://bugs.llvm.org/show_bug.cgi?id=37294">37294</a>
          </td>
        </tr>

        <tr>
          <th>Summary</th>
          <td>lldb-server can deadlock in ack-mode
          </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>enhancement
          </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>labath@google.com
          </td>
        </tr>

        <tr>
          <th>CC</th>
          <td>llvm-bugs@lists.llvm.org
          </td>
        </tr></table>
      <p>
        <div>
        <pre>lldb-server is a single-threaded event-driven app and uses the MainLoop class
to manage events and their actions. It's two main sources of events are a
network socket (requests from the client) and SEGV signals (events in the
inferior).

Normally everything works fine, if we have a very fast client (or a heavily
loaded system) which tries to communicate with lldb-server in ack-mode, things
can break down. The sequence of events if approximately like this:
1. inferior stops for some reason (event A)
2. lldb-server sends a stop-reply packet
3. lldb-server waits for acknowledgement from the client.
- now if the client is really fast, he will manage to also send a regular
packet in addition to a acknowledgement
4. GetAck will read both of these things, but process only the acknowledgement,
and store the rest in a side buffer
5. event A processing done, mainloop calls ppoll()
- at this point, we should wake up and process the client request, however,
ppoll blocks because as far as it is concerned, the event has already been
processed
- so server blocks waiting for data, and client blocks waiting for the server
to respond - deadlock.

I have a couple of ideas how to fix this, but none of them seemed completely
appealing. This issue only affects the lldb-server gtests, because they are the
only ones running in ack-mode. Given that this was more of an omission than
explicit intent, I am going to switch the tests to noack-mode as a stop-gap
measure, to make sure the tests are not flaky.</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>