<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 - TestGuiBasicDebug.py is flaky - lack of process event synchronization ?"
href="https://bugs.llvm.org/show_bug.cgi?id=51833">51833</a>
</td>
</tr>
<tr>
<th>Summary</th>
<td>TestGuiBasicDebug.py is flaky - lack of process event synchronization ?
</td>
</tr>
<tr>
<th>Product</th>
<td>lldb
</td>
</tr>
<tr>
<th>Version</th>
<td>unspecified
</td>
</tr>
<tr>
<th>Hardware</th>
<td>All
</td>
</tr>
<tr>
<th>OS</th>
<td>All
</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>jdevlieghere@apple.com, llvm-bugs@lists.llvm.org
</td>
</tr></table>
<p>
<div>
<pre>Once every while, the "finish" command in the test fails to step out of the
designated function. Or rather, it fails to stop after stepping out of the
function -- instead, it continues stepping until the application terminates.
My analysis of the test logs (see attachment) suggests that this if due to poor
event handling discipline. After requesting an (asynchronous) step out, the gui
command goes back to its normal business. The first order of business is
usually to redraw the screen (see Application::Run). If it does that too
quickly, it can happen that the command will start drawing the threads before
the "running" event propagates to public. This means that the all the
StateIsStoppedState guards that the command uses to prevent accessing a running
process will fail. This will cause lldb to start computing (a bogus) the stack
frame list in parallel to its internal processing of the step over operation.
When the inferior stops, the step over thread plan will be presented with the
inconsistent stack frame, which will cause it to think that it has _not_
stepped out of the function, and will trigger another resume. That will
terminate the inferior.
It's not fully clear to me how to fix this. Presumably, the gui should process
the running event resulting from the resume command before doing anything else.
It has some code which tries to do that, but since it only does a poll, it will
not capture the event if it has not been already sent.
It also seems that the process run lock should have prevented anyone from
tampering with the process while it was running.</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>