<div dir="ltr">In addition to the (lldb) prompt out of order, I am also investigating some other strange messages when I run a simple application with no breakpoints. It seems related to thread synchronization surrounding the startup/management of the inferior process.<br>
<br>(lldb) run<br><br>Process 4417 launching<br>Process 4417 stopped<br>* thread #1: tid = 4417, 0x00007f3b99b9c2d0, name = 'a.out', stop reason = trace<br> frame #0: 0x00007f3b99b9c2d0<br>-> 0x7f3b99b9c2d0: movq %rsp, %rdi<br>
0x7f3b99b9c2d3: callq 0x7f3b99b9fa70<br> 0x7f3b99b9c2d8: movq %rax, %r12<br> 0x7f3b99b9c2db: movl 0x221b17(%rip), %eax<br><br>Process 4417 launched: '/home/shawn/Projects/a.out' (x86_64)<br>Hello world!<br>
The string is Test String : 5 <br>Process 4417 exited with status = 0 (0x00000000) <br>(lldb)<br><br>------------- or ----------------<br><br>(lldb) run<br><br>Process 4454 launching<br>Process 4454 launched: '/home/shawn/Projects/a.out' (x86_64)<br>
Process 4454 stopped<br>* thread #1: tid = 4454, 0x00007ffdec16c2d0, name = 'a.out', stop reason = trace<br> frame #0: 0x00007ffdec16c2d0<br>error: No such process<br><br>Hello world!<br>The string is Test String : 5 <br>
Process 4454 exited with status = 0 (0x00000000) <br>(lldb) <br><br><br>As it is launching the target application, it appears to stop in a random place (stop reason = trace), and then continue exectuting. When it momentarily stops, I see it pop/push an IOHandler. <br>
<br>I added some logging to ProcessPOSIX, and see it hitting RefreshAfterStop() and DoResume() many times. Is this normal/expected?<br><br>I have added a bunch of logging to Push/Pop IOHandler, ThreadCreate, HandleProcessEvent and see big differences in the order of events changing from run to run.<br>
<br><br>One other small thing, in POSIX/ProcessMonitor, it calls waitpid() and checks the return code,<br><br> lldb::pid_t wpid;<br> if ((wpid = waitpid(pid, &status, 0)) < 0)<br> {<br> args->m_error.SetErrorToErrno();<br>
goto FINISH;<br> }<br> else ...<br><br>lldb::pid_t is a uint64, while waitpid returns an int32, with negative numbers used for error codes.<br>This bug is repeated in a few places<br><br><div class="gmail_extra">
Shawn.<br></div><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Jun 20, 2014 at 3:34 PM, Greg Clayton <span dir="ltr"><<a href="mailto:gclayton@apple.com" target="_blank">gclayton@apple.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div class=""><div class="h5"><br>
> On Jun 19, 2014, at 7:27 PM, Ed Maste <<a href="mailto:emaste@freebsd.org">emaste@freebsd.org</a>> wrote:<br>
><br>
> Hi Greg,<br>
><br>
> As far as I can tell what's happening here is just that<br>
> Process::Resume() completes and the next prompt is emitted (from the<br>
> main-thread?) before the IOHandler gets pushed in another thread.<br>
><br>
> Output from "log enable -n lldb process" with an added log printf<br>
> where ::Resume returns:<br>
><br>
> step<br>
> main-thread Process::Resume -- locking run lock<br>
> main-thread Process::PrivateResume() m_stop_id = 4, public state:<br>
> stopped private state: stopped<br>
> main-thread Process::SetPrivateState (running)<br>
> main-thread Process thinks the process has resumed.<br>
> internal-state(p Process::ShouldBroadcastEvent (0x80c410480) => new<br>
> state: running, last broadcast state: running - YES<br>
> main-thread Process::PrivateResume() returning<br>
> (lldb) internal-state(p Process::HandlePrivateEvent (pid = 15646)<br>
> broadcasting new state running (old state stopped) to public<br>
> wait4(pid=15646) MonitorChildProcessThreadFunction ::waitpid (pid =<br>
> 15646, &status, options = 0) => pid = -15646, status = 0x0000057f<br>
> (STOPPED), signal = 5, exit_state = 0<br>
> internal-state(p PushIOHandler<br>
> wait4(pid=15646) Process::SetPrivateState (stopped)<br>
><br>
> As before, I don't see how we intend to enforce synchronization<br>
> between those two threads. It looks like my tiny usleep in<br>
> ::PrivateResume delays the next prompt just long enough for the other<br>
> IOHandler to be pushed.<br>
<br>
</div></div>That will do it. It is tough because Process::Resume() might not succeed so we can't always push the ProcessIOHandler.<br>
<br>
I need to find a better way to coordinate the pushing of the ProcessIOHandler so it happens from the same thread that initiates the resume. Then we won't have this issue, but I need to carefully do this so it doesn't push it when the process won't be resumed (since it might already be resumed) or in other edge cases.<br>
<br>
Other ideas would be to have the Process::Resume() do some synchronization between the current thread and the internal-state thread so it waits for the internal-state thread to get to the running state before it returns from Process::Resume()...<br>
<span class=""><font color="#888888"><br>
Greg<br>
<br>
</font></span></blockquote></div><br></div></div>