[lldb-dev] strange behaviour at lldb cmd line

Ed Maste emaste at freebsd.org
Thu Jun 19 19:27:52 PDT 2014


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.

-Ed


On 19 June 2014 17:20, Greg Clayton <gclayton at apple.com> wrote:
> I usually find it best to debug one LLDB using another and step through the Debugger::HandleProcessEvent () and watch as things come out wrong.
>
>
>> On Jun 19, 2014, at 2:08 PM, Shawn Best <sbest at blueshiftinc.com> wrote:
>>
>> Thanks for the pointers Greg and Ed. Lots to chew on.  I will get back with what I find.
>>
>> Shawn.
>> On 6/19/2014 12:18 PM, Ed Maste wrote:
>>>>> On Jun 19, 2014, at 10:29 AM, Shawn Best <sbest at blueshiftinc.com> wrote:
>>>>>
>>>>> Hi All,
>>>>>
>>>>> I would like to start contributing to lldb project and help improve it on linux.  I am seeing some strange behaviour that makes lldb appear a little flakey.  Some details of my system:
>>>>>
>>>>> - Ubuntu 14.04, 64 bit running inside a VM on windows
>>>>> - built from top of top of tree with gcc 4.8.2.  Issue happens either configure/make or cmake/ninja
>>>>> - stock lldb-3.4 version shipped with Ubuntu does not exhibit this behaviour
>>>>>
>>>>> There are two intermittent issues:  1. When I run a program, I see messages that do not belong (indicating the process was stopped)  2.  There appears to be a race condition sending text to the console where (lldb) prompt will come out of order making it appear there is no command prompt.
>>> Hi Shawn,
>>>
>>> There are also some previous threads on this topic in the archives
>>> that could help give you some background.  The discussion was in reply
>>> to the r202525 commit message.
>>>
>>> I described a hacky workaround that works for me in:
>>> http://lists.cs.uiuc.edu/pipermail/lldb-commits/Week-of-Mon-20140519/011166.html
>>>
>>> Can you give it a try?  If it "works" for you that will at least
>>> suggest we share the same issue on FreeBSD and Linux.
>>>
>>> -Ed
>>
>> _______________________________________________
>> lldb-dev mailing list
>> lldb-dev at cs.uiuc.edu
>> http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev
>
> _______________________________________________
> lldb-dev mailing list
> lldb-dev at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev




More information about the lldb-dev mailing list