[lldb-dev] strange behaviour at lldb cmd line

[Shawn Best]

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.

(lldb) run

Process 4417 launching
Process 4417 stopped
* thread #1: tid = 4417, 0x00007f3b99b9c2d0, name = 'a.out', stop reason =
trace
    frame #0: 0x00007f3b99b9c2d0
-> 0x7f3b99b9c2d0:  movq   %rsp, %rdi
   0x7f3b99b9c2d3:  callq  0x7f3b99b9fa70
   0x7f3b99b9c2d8:  movq   %rax, %r12
   0x7f3b99b9c2db:  movl   0x221b17(%rip), %eax

Process 4417 launched: '/home/shawn/Projects/a.out' (x86_64)
Hello world!
The string is  Test String :  5
Process 4417 exited with status = 0 (0x00000000)
(lldb)

------------- or ----------------

(lldb) run

Process 4454 launching
Process 4454 launched: '/home/shawn/Projects/a.out' (x86_64)
Process 4454 stopped
* thread #1: tid = 4454, 0x00007ffdec16c2d0, name = 'a.out', stop reason =
trace
    frame #0: 0x00007ffdec16c2d0
error: No such process

Hello world!
The string is  Test String :  5
Process 4454 exited with status = 0 (0x00000000)
(lldb)


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.

I added some logging to ProcessPOSIX, and see it hitting RefreshAfterStop()
and DoResume() many times. Is this normal/expected?

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.


One other small thing, in POSIX/ProcessMonitor, it calls waitpid() and
checks the return code,

    lldb::pid_t wpid;
    if ((wpid = waitpid(pid, &status, 0)) < 0)
    {
        args->m_error.SetErrorToErrno();
        goto FINISH;
    }
    else  ...

lldb::pid_t is a uint64, while waitpid returns an int32, with negative
numbers used for error codes.
This bug is repeated in a few places

Shawn.

On Fri, Jun 20, 2014 at 3:34 PM, Greg Clayton <gclayton at apple.com> wrote:

>
> > On Jun 19, 2014, at 7:27 PM, Ed Maste <emaste at freebsd.org> wrote:
> >
> > Hi Greg,
> >
> > As far as I can tell what's happening here is just that
> > Process::Resume() completes and the next prompt is emitted (from the
> > main-thread?) before the IOHandler gets pushed in another thread.
> >
> > Output from "log enable -n lldb process" with an added log printf
> > where ::Resume returns:
> >
> > step
> > main-thread Process::Resume -- locking run lock
> > main-thread Process::PrivateResume() m_stop_id = 4, public state:
> > stopped private state: stopped
> > main-thread Process::SetPrivateState (running)
> > main-thread Process thinks the process has resumed.
> > internal-state(p Process::ShouldBroadcastEvent (0x80c410480) => new
> > state: running, last broadcast state: running - YES
> > main-thread Process::PrivateResume() returning
> > (lldb) internal-state(p Process::HandlePrivateEvent (pid = 15646)
> > broadcasting new state running (old state stopped) to public
> > wait4(pid=15646) MonitorChildProcessThreadFunction ::waitpid (pid =
> > 15646, &status, options = 0) => pid = -15646, status = 0x0000057f
> > (STOPPED), signal = 5, exit_state = 0
> > internal-state(p PushIOHandler
> > wait4(pid=15646) Process::SetPrivateState (stopped)
> >
> > As before, I don't see how we intend to enforce synchronization
> > between those two threads.  It looks like my tiny usleep in
> > ::PrivateResume delays the next prompt just long enough for the other
> > IOHandler to be pushed.
>
> That will do it. It is tough because Process::Resume() might not succeed
> so we can't always push the ProcessIOHandler.
>
> 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.
>
> 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()...
>
> Greg
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/lldb-dev/attachments/20140626/39314f3d/attachment.html>